Tại sao kết nối MySQL không hoạt động?
Phản hồi đã được gửi thành công Cảm ơn bạn đã phản hồi có giá trị. Chúng tôi sẽ sử dụng nó để tạo matomo. tổ chức thậm chí còn tốt hơn Show
Làm cách nào để khắc phục lỗi Mysql “Kết nối bị từ chối”? Lỗi máy chủ MySQL 6 có thể do một số nguyên nhân, nếu bạn làm theo các bước bên dưới, bạn sẽ có thể khắc phục sự cố này
Nếu bạn vẫn có 6 sau khi kiểm tra các bước trên, vui lòng liên hệ với chúng tôi bằng cách nhấp vào nút phản hồi bên dưới Nếu bạn đang gặp phải lỗi kết nối cơ sở dữ liệu, thì không cần tìm đâu xa để được hỗ trợ khắc phục sự cố. Hướng dẫn này trình bày chi tiết các nguyên nhân phổ biến gây ra lỗi kết nối Cơ sở dữ liệu đáng sợ, cách tìm ra nguyên nhân gốc rễ và những việc cần làm để khắc phục nó. Các lệnh trong bài viết này hoạt động với MySQL hoặc MariaDB trên máy chủ cPanel CentOS 6 hoặc 7 Tôi biết rằng đây là khoảng thời gian khó chịu và bạn đang gấp rút sửa trang web của mình, vì vậy tôi đã liệt kê bên dưới các nguyên nhân phổ biến nhất gây ra Lỗi kết nối cơ sở dữ liệu theo thứ tự phổ biến để giúp bạn tìm và khắc phục sự cố này nhanh nhất có thể (don
Điều đầu tiên bạn nên tự hỏi mình khi gặp lỗi này là "Lỗi này liên tục hay gián đoạn?". Thứ hai, "Điều này xảy ra với tất cả các trang web hay chỉ một trang web?" Nếu lỗi không liên tục, hãy kiểm tra những điều sau
Nếu lỗi vẫn còn nhưng xảy ra với tất cả các trang web, hãy kiểm tra những điều sau
Nếu lỗi vẫn còn, nhưng chỉ xảy ra với một trang web, hãy kiểm tra những điều sau
Bài viết này thảo luận chi tiết cách xử lý các biến thể lỗi sau đây mà bạn có thể thấy được ghi vào các vị trí khác nhau trong máy chủ của mình
Lỗi hết bộ nhớNếu lỗi không liên tục, bạn nên kiểm tra lỗi OOM hoặc lỗi Hết bộ nhớ. Để kiểm tra OOM, bạn có thể chạy lệnh sau
Bạn có thể thấy đầu ra có lỗi tương tự như thế này Nếu đúng như vậy, thì bạn nên kiểm tra ngay domlog của mình (nhật ký truy cập miền) để phát hiện hành vi lạm dụng, chẳng hạn như ép buộc đăng nhập WordPress, lạm dụng XMLRPC hoặc tấn công DoS. Vui lòng liên hệ với bộ phận hỗ trợ của Knownhost để được trợ giúp về vấn đề này nếu bạn gặp phải lỗi Hết bộ nhớ Nếu không có sự lạm dụng nào xảy ra, bạn có thể muốn kiểm tra đầu ra của sar để xác định xem chúng đã xảy ra trong bao lâu để bạn có thể xác định xem bạn có đang chạy máy chủ của mình với thiếu RAM hay không. Sar chỉ lưu trữ thông tin trong 30 ngày qua, nhưng ít nhất sẽ cung cấp cho bạn tổng quan về việc sử dụng RAM trong tháng qua. Đây là cách kiểm tra mức sử dụng RAM của ngày hiện tại với sar
Lệnh sau có thể được sử dụng để kiểm tra việc sử dụng RAM vào ngày trước ngày 13
Bạn có thể sử dụng lệnh trên để kiểm tra bất kỳ ngày nào trong 30-31 ngày qua bằng cách thay '13' bằng ngày mà bạn muốn kiểm tra. Nếu 'dd' đại diện cho ngày, thì sau đây là tổng quát
Chỉ cần thay 'dd' bằng ngày trong tháng mà bạn muốn xem lại mức sử dụng RAM Ngoài ra, bạn có thể sử dụng lệnh sau để kiểm tra tổng số OOM đã xảy ra trên VPS của mình (lệnh này không hoạt động đối với các bộ chứa không được ảo hóa)
Số cuối cùng được liệt kê là số lượng OOM. Nếu không có OOM nào xảy ra, thì đầu ra của bạn sẽ như thế này Nếu đã xảy ra OOM, như trong trường hợp máy chủ sau có 126 nghìn lỗi, bạn sẽ thấy số lượng OOM đã xảy ra Nếu OOM xảy ra quá thường xuyên để ghi lại qua /var/log/messages, thì bạn sẽ muốn xem con số này. Điều này đôi khi xảy ra khi OOM đang xảy ra nhưng không được đăng nhập trên máy chủ, mặc dù số lỗi được ghi vào /proc/user_beancounters Nếu bạn phát hiện hành vi lạm dụng, tùy thuộc vào loại hành vi lạm dụng xảy ra, bạn có thể thực hiện một số hành động. Bạn có thể ẩn đăng nhập wp. php, vô hiệu hóa quyền truy cập vào xmlrpc. php của bạn, chặn các bot 'xấu', chặn các IP bắt nguồn từ hành vi lạm dụng (nếu hành vi lạm dụng bắt nguồn từ một đến một vài IP) và xem xét một dịch vụ như Cloudflare cung cấp khả năng bảo vệ khỏi các cuộc tấn công DoS và sẽ giúp giảm thiểu các cuộc tấn công của bạn. . Đây sẽ là những giải pháp cho các loại lạm dụng phổ biến nhất mà chúng tôi thấy Nếu bạn thấy không có hành vi lạm dụng nào xảy ra, bạn có thể cân nhắc bổ sung thêm RAM hoặc tắt các dịch vụ sử dụng nhiều RAM mà chúng có thể không cần thiết hoặc đang được sử dụng (cPanel-Solr và Clamd không bắt buộc và được biết là cần nhiều RAM) Bạn cũng có thể kiểm tra nhiều phiên bản của cùng một dịch vụ đang chạy. Một lỗi gần đây trong cPanel gây ra nhiều OOM do nhiều trường hợp tailwatchd được khởi tạo liên tục. Nếu bạn thấy điều gì đó tương tự xảy ra, rất có thể cPanel đã biết và đã phát hành một bản vá, vì vậy bạn có thể dừng các dịch vụ đó, xóa chúng khỏi Trình quản lý dịch vụ đủ lâu để chạy bản cập nhật, sau đó thêm dịch vụ trở lại Dịch vụ . Nếu sự cố vẫn tiếp diễn, vui lòng gửi yêu cầu hỗ trợ với nhóm hỗ trợ Knownhost Dung lượng ổ đĩa vượt quáĐể biết dung lượng đĩa có bị vượt quá hay không, hãy chạy lệnh sau qua SSH với quyền root
Bạn sẽ thấy một cái gì đó tương tự như thế này cho biết rằng bạn đã sử dụng hết 100% dung lượng ổ đĩa hoặc chỉ còn trong MB để làm như vậy Hoặc thử đăng nhập vào WHM. Lỗi sau thường xuất hiện khi bạn đã vượt quá dung lượng ổ đĩa và cố gắng truy cập WHM Khi dung lượng ổ đĩa của bạn bị vượt quá, bạn chỉ có thể sửa nó bằng cách truy cập qua SSH. Nếu bạn không thoải mái với SSH, hãy mở một yêu cầu hỗ trợ với bộ phận hỗ trợ KH đặt mức độ ưu tiên Quan trọng và chúng tôi sẽ nhanh chóng làm việc để tìm ra thứ đang chiếm dung lượng và giúp bạn trực tuyến trở lại Bạn có thể sử dụng lệnh sau để tìm thư mục nào bên dưới root đang sử dụng nhiều dung lượng ổ đĩa nhất
Bạn sẽ nhận được đầu ra tương tự như thế này Đối với máy chủ cụ thể này, bạn có thể thấy rằng 22G nằm trong /backup và 11G trong /home. Nếu bạn muốn tìm hiểu sâu hơn về những gì trong /home, bạn có thể làm như sau
Nếu bạn thấy rằng hầu hết dung lượng ổ đĩa trong /home thuộc một tài khoản, giả sử tài khoản 'cpuser' thì bạn có thể xem trong tài khoản đó như sau ________số 8Và sau đó, nếu bạn thấy rằng dung lượng ổ đĩa trong tài khoản đó chủ yếu là do thư, bạn có thể tìm thấy tài khoản email nào chịu trách nhiệm như sau
Do đó, bạn có thể biết được thư mục nào đang chiếm nhiều dung lượng nhất bằng cách kiểm tra các thư mục lớn nhất trên máy chủ bằng cách sử dụng lệnh du Ghi chú. Lý do của thẻ –exclude virtfs ở trên là do không bao gồm đầu ra virtfs. Lý do là virtfs sẽ hiển thị rất nhiều dung lượng được sử dụng, tuy nhiên, không gian thực sự không được sử dụng. /home/virtfs bao gồm các liên kết gắn kết. và không thực sự chiếm dung lượng ổ đĩa, mặc dù nó sẽ hiển thị dưới dạng dung lượng ổ đĩa đã sử dụng khi bạn sử dụng du. Không sử dụng rm hoặc cố xóa thư mục /home/virtfs vì làm như vậy cũng sẽ xóa nội dung mà thư mục được gắn vào và có khả năng khiến máy chủ của bạn không hoạt động. Nếu bạn muốn tháo các mount này thì xem link sau tài liệu. cpanel. net/display/68Docs/VirtFS+-+Jailed+Shell Kết nối tối đaĐể tìm hiểu xem max_connections được cấu hình của MySQL có bị vượt quá hay không, bạn có thể so sánh đầu ra của các lệnh sau 0Bạn sẽ thấy đầu ra tương tự như sau Nếu giá trị của Max_used_connections từ lệnh đầu tiên là giá trị của max_connections + 1 trở lên, thì max_connections cho MySQL đã bị vượt quá. Ví dụ: nếu Max_used_connections là 51 nhưng max_connections là 50, thì bạn đã vượt quá max_connections của mình. Miễn là lưu lượng có vẻ hợp pháp và bạn có đủ RAM để hỗ trợ việc tăng, bạn có thể tăng cài đặt này trong tệp cấu hình MySQL bằng cách thực hiện như sau 1) chỉnh sửa/etc/của tôi. cnf và thay đổi cài đặt như mong muốn, nhưng hãy thực hiện từng bước nhỏ để không làm cạn kiệt RAM của bạn 2) khởi động lại MySQL Điều này có thể được thực hiện với các lệnh sau 1Ctrl X để thoát. Bạn sẽ được nhắc xác nhận các thay đổi và tên tệp. Cuối cùng, khởi động lại MySQL 2PHPGần đây bạn có nâng cấp PHP lên phiên bản 7 không? . Chức năng này không còn được dùng nữa và phần mềm trang web sẽ cần được nâng cấp để tương thích với PHP 7, (thay vào đó hãy sử dụng mysqli_connect). Bạn có thể chạy tìm kiếm sau qua SSH trong thư mục gốc của trang web để kiểm tra 3Về Thiếu mô-đun, đây hiếm khi là một vấn đề. Tuy nhiên, đây là những mô-đun thường được sử dụng để thiết lập kết nối cơ sở dữ liệu (thay đổi tùy thuộc vào phiên bản EasyApache/CustomBuild và PHP bạn đang sử dụng)
Thông tin xác thực cơ sở dữ liệu không khớpMột nguyên nhân có thể khác là có thể có thông tin đăng nhập không hợp lệ hoặc không khớp trong tệp cấu hình cơ sở dữ liệu của trang web so với các tệp được lưu trữ trong bảng điều khiển/MySQL. Điều này thường xảy ra khi quá trình di chuyển được thực hiện và trước đây bạn đang sử dụng hàm băm mật khẩu MySQL cũ, kém an toàn hơn. cPanel sẽ thay đổi mật khẩu thành mật khẩu ngẫu nhiên, an toàn bằng cách sử dụng định dạng băm mật khẩu mới để cung cấp cho bạn khả năng bảo mật tối đa, tuy nhiên, bạn phải cập nhật mật khẩu trong cPanel để khớp với mật khẩu có trong tệp cấu hình của mình sau khi thực hiện xong Sau đây liệt kê các vị trí (đường dẫn có liên quan đến thư mục gốc của cài đặt) của các tệp cấu hình lưu trữ thông tin đăng nhập cơ sở dữ liệu cho một số CMS phổ biến
Khi bạn truy xuất tên cơ sở dữ liệu, tên người dùng và mật khẩu từ các tệp này, bạn sẽ cần đăng nhập vào cPanel cho miền và cập nhật mật khẩu của người dùng cơ sở dữ liệu
Bây giờ bạn có thể xóa bộ nhớ cache của trình duyệt và kiểm tra xem điều này đã giải quyết được Lỗi kết nối cơ sở dữ liệu của bạn hay chưa Các bảng MyIsam bị lỗi, hỏng hoặc bị hỏng trong MySQLCuối cùng, vấn đề tồi tệ nhất có thể xảy ra… MySQL bị lỗi/hỏng hoặc các bảng bị sập. Trường hợp xấu nhất không tệ đến thế nhờ có Knownhost và hệ thống sao lưu bên ngoài của họ. Nếu không thể sửa lỗi MySQL InnoDB, chúng tôi có thể thử khôi phục máy chủ về bản sao lưu trước đó, bản sao lưu này có thể không có nhiều lỗi và sau đó sửa lỗi thành công Để kiểm tra các lỗi này, điều đầu tiên phải làm là kiểm tra xem MySQL có đang chạy không 4Sau đó, bạn sẽ muốn kiểm tra các bản ghi MySQL để tìm lỗi như hình bên dưới 5Lệnh sẽ hiển thị 400 lỗi cuối cùng. Bạn có thể điều chỉnh số lượng lỗi để hiển thị khi bạn thấy phù hợp. Nếu nhật ký lỗi của bạn ở một vị trí khác, bạn sẽ muốn điều chỉnh lệnh cho phù hợp Điều này sẽ cung cấp cho bạn manh mối về vấn đề là gì. Nếu bạn vẫn không chắc chắn và MySQL đang chạy trong lần kiểm tra trước, bạn có thể theo dõi nhật ký lỗi MySQL trong khi cố gắng khởi động lại MySQL trong một phiên ssh khác và điều này sẽ cung cấp cho bạn thêm manh mối về lý do xảy ra các lỗi này. Điều chỉnh nhật ký bằng lệnh này 6Và, trong một thiết bị đầu cuối khác, hãy khởi động lại MySQL bằng lệnh sau 2Lỗi cú phápNếu có lỗi cú pháp trong tệp cấu hình MySQL, lỗi sẽ được ghi lại chi tiết lỗi chính xác. Sau đó, bạn có thể chỉnh sửa /etc/my. cnf để nhận xét hoặc đặt ký hiệu # trước câu lệnh có lỗi cú pháp để vô hiệu hóa nó. Sau đó, hãy thử khởi động MySQL 8Nếu không có lỗi cú pháp rõ ràng và nhật ký lỗi có rất nhiều số 0,. ’s, và có vẻ như MySQL không mạch lạc và say sưa đăng nhập vào nhật ký lỗi, thì có khả năng lỗi của InnoDB là nguyên nhân. Nhật ký cũng có thể tham chiếu rõ ràng một bài viết từ MySQL về InnoDB Forced Recovery. Nếu đây là trường hợp, InnoDB Forced Recovery phải được thực hiện Phục hồi cưỡng bức InnoDBMySQL có thể hoặc không thể chạy. Nó có thể bị sập ngay khi khởi động lại và đăng các lỗi không có ý nghĩa gì. Nó cũng có thể tham khảo một liên kết đến một bài viết về MySQL về việc khôi phục InnoDB QUAN TRỌNG Đảm bảo bạn có đủ RAM và OOM không xảy ra trước khi bạn khôi phục InnoDB. Ngoài ra, hãy đảm bảo rằng bạn xóa MySQL khỏi Trình quản lý dịch vụ trước khi thực hiện bất kỳ bước khôi phục nào bên dưới, sau đó đảm bảo đảo ngược bước này sau khi bạn đã khôi phục InnoDB. Bạn có thể bật và tắt tính năng 'được giám sát' bằng cách sử dụng lệnh WHM API. Lệnh bên dưới sẽ tắt nó (thay thế '0' bằng '1' cho 'được giám sát' để bật lại) 9Điều đầu tiên bạn muốn làm là mở một thiết bị đầu cuối thứ hai và xem nhật ký lỗi MySQL khi bạn buộc khôi phục InnoDB. Bạn có thể xem nhật ký lỗi bằng lệnh sau 6Xem nhật ký lỗi trong khi thực hiện các bước bên dưới sẽ cho phép bạn xác định xem lỗi InnoDB đã được sửa hay chưa vì bạn sẽ không còn thấy lỗi cho biết lỗi InnoDB xuất hiện và MySQL sẽ hoạt động trở lại Nếu MySQL bị dừng, bạn cũng có thể muốn chạy phần sau trước khi bắt đầu chỉ để đảm bảo rằng không có bảng MyISAM nào bị lỗi ngăn cản các kết xuất mysql của bạn hoàn thành 1Để thực hiện Forced InnoDB Recovery, bạn phải làm như sau
Nếu MySQL không khởi động được, hãy thử tiếp tục với innodb_force_recovery=2. Bạn có thể đi đến 6, nhưng bạn muốn bắt đầu với giá trị thấp nhất có thể. Giá trị của innodb_force_recovery càng cao thì khả năng mất dữ liệu càng nhiều Nếu MySQL bắt đầu, thì hãy tiến hành các bước sau 2Bây giờ, dừng MySQL 3Trong khi dừng lại, hãy làm như sau 4Bây giờ, chỉnh sửa /etc/my. cnf và nhận xét (đặt ký hiệu # trước) innodb_force_recovery=1 5Nếu MySQL vẫn không thành công, hãy thử lặp lại quá trình khôi phục bắt buộc của Innodb với cài đặt cao hơn. Nếu bạn đạt đến 6 mà không thành công, bạn có thể muốn yêu cầu nhóm hỗ trợ khôi phục /var/lib/mysql từ một ngày trước đó khi tham nhũng hy vọng không quá tệ và sau đó thử lại InnoDB bắt buộc khôi phục Nếu bạn không thấy lỗi nào ở trên (lỗi cú pháp hoặc hỏng InnoDB), bạn có thể kiểm tra các bảng MyISAM bị lỗi Bảng MyIsam bị sậpĐể kiểm tra các bảng MyISAM bị lỗi, hãy chạy lệnh sau và nếu có lỗi, hãy kiểm tra xem ngày hiện tại có phải là ngày hiện tại không (cPanel sẽ phát hiện và tự động sửa các bảng bị lỗi cho bạn trong hầu hết các trường hợp, 6Bạn sẽ thấy các lỗi như thế này 7May mắn thay, việc sửa chữa các bảng MyISAM thực sự khá dễ dàng. Bạn có thể làm như vậy bằng cách chạy các lệnh sau 8QUAN TRỌNG Đảm bảo bạn có đủ RAM và không xảy ra hiện tượng OOM trước khi sửa chữa bảng của mình Bạn thậm chí có thể sử dụng các phương tiện thay thế sau đây để sửa chữa bảng 9Hoặc sau đây để sửa chữa cơ sở dữ liệu 0Lưu ý rằng myisamchk có thể chạy khi MySQL không chạy, trong khi đó mysqlcheck và bảng sửa chữa chỉ có thể chạy khi MySQL đang chạy Bạn sẽ thay thế DATABASE bằng tên của cơ sở dữ liệu và TABLENAME bằng tên bảng. Bạn nhận được những thứ này trực tiếp từ lỗi đã ghi ở trên, có định dạng yymmdd hh. mm. ss [LỖI] mysqld. Bàn '. /database_name/table_name’ được đánh dấu là bị lỗi và cần được sửa chữa Đây là những gì loại sửa chữa này trông giống như Đôi khi, sửa chữa này sẽ thất bại do một bảng tạm thời. Lỗi sẽ đọc một cái gì đó tương tự như thế này 1Đây là lỗi này trông như thế nào khi bạn gặp phải sau khi cố gắng sửa chữa một bảng thông qua MySQL CLI Lưu ý rằng 'TMD' sẽ thực sự được viết hoa trong máy chủ của bạn, trong khi '/DATABASE_NAME/TABLE_NAME' thực tế sẽ là chữ thường Nếu điều này xảy ra, bạn sẽ cần xóa bảng tạm thời. Tôi muốn đổi tên nó để giữ nguyên bản sao, có thể thực hiện việc này thông qua lệnh sau 2Bây giờ bạn có thể chạy sửa chữa thành công Nếu bạn có nhiều bảng bị lỗi, bạn có thể sử dụng lệnh sau để kiểm tra, phân tích, tối ưu hóa và sửa chữa tất cả các bảng (một số chức năng này chỉ hoạt động với một số công cụ lưu trữ nhất định, chẳng hạn như sửa chữa bằng MyISAM) 3Bạn có thể muốn xem nhật ký lỗi trong một thiết bị đầu cuối riêng biệt trong khi chạy lệnh này 6Nếu cơ sở dữ liệu của bạn rất lớn, thì bạn có thể muốn sử dụng tiện ích màn hình để chạy lệnh ở trên để đảm bảo rằng nó có thể hoàn thành ngay cả khi bạn đăng xuất 5Phần kết luậnGiữ bản sao lưu MySQL thường xuyên. Cái này rất quan trọng. Knownhost thực hiện sao lưu VPS đầy đủ cho khách hàng VPS của chúng tôi mỗi ngày và cung cấp các giải pháp sao lưu tuyệt vời cho khách hàng máy chủ chuyên dụng của chúng tôi. Có một số hạn chế đối với các bản sao lưu của chúng tôi có thể được khắc phục bằng các bản sao lưu cPanel, vì vậy các bản sao lưu cPanel chắc chắn được khuyên dùng Rõ ràng, chúng tôi không muốn bạn giải quyết những vấn đề này một mình, đặc biệt nếu bạn không quen với SSH. Chúng tôi ở đây để giúp đỡ. Nếu bạn gặp phải bất kỳ vấn đề nào trong số này, vui lòng gửi yêu cầu hỗ trợ và chúng tôi sẽ sẵn lòng hỗ trợ. Bất kể trường hợp nào, chúng tôi sẽ cố gắng hết sức để máy chủ của bạn hoạt động và trực tuyến ngay khi có thể. Chúng tôi ở đây để giúp đỡ |