Error Establishing a Database Connection — Cách khắc phục

Thu hẹp nguyên nhân trong hai phút

Trước khi động vào bất cứ file nào, hãy trả lời một câu hỏi: dịch vụ cơ sở dữ liệu có đang chạy không?

Nếu có SSH, chạy "systemctl status mysql" hoặc "systemctl status mariadb". Nếu dùng shared hosting, thử mở phpMyAdmin trong bảng điều khiển — vào được nghĩa là dịch vụ vẫn sống và thông tin đăng nhập của website mới là vấn đề.

Nguyên nhân 1 — Sai thông tin đăng nhập

Đây là nguyên nhân phổ biến nhất ngay sau khi chuyển nhà website, khôi phục bản sao lưu, hoặc đổi mật khẩu trong bảng điều khiển hosting.

Với WordPress, bốn giá trị trong wp-config.php phải khớp chính xác: DB_NAME, DB_USER, DB_PASSWORD và DB_HOST. Chỗ sai nhiều nhất là DB_HOST — "localhost" đúng trên phần lớn máy chủ nhưng một số nhà cung cấp dùng một hostname riêng, và giá trị đúng luôn có trong bảng điều khiển hosting.

Chỗ sai nhiều thứ hai là tiền tố tên user và tên database. Nhiều bảng điều khiển tự thêm tiền tố tài khoản, nên database bạn tạo tên "wordpress" thực tế lại là "user123_wordpress".

Kiểm tra nhanh bằng cách tự kết nối: "mysql -u tenuser -p -h localhost tendatabase". Nếu lệnh này vào được mà website vẫn lỗi, thông tin đăng nhập không phải vấn đề và bạn có thể chuyển sang phần sau.

Nguyên nhân 2 — Dịch vụ cơ sở dữ liệu đã chết

Khi MySQL hoặc MariaDB không chạy, mọi website trên máy chủ đều báo cùng một lỗi. Khởi động lại thường khôi phục ngay, nhưng dừng ở đó là bỏ lỡ phần quan trọng.

Nguyên nhân gần như luôn là hết bộ nhớ. VPS nhỏ chạy đồng thời web server, PHP và cơ sở dữ liệu sẽ chạm trần RAM vào lúc đông khách, kernel chọn tiến trình ngốn bộ nhớ nhất để giết, và đó thường chính là MySQL.

Chạy "dmesg | grep -i oom" để xem kernel có ra tay hay không. Nếu có, việc khởi động lại chỉ mua thêm thời gian tới lần kế tiếp — cách xử lý thật là thêm swap, giảm mức tiêu thụ bộ nhớ của cơ sở dữ liệu, hoặc nâng RAM.

Nguyên nhân thứ hai là hết dung lượng đĩa. Cơ sở dữ liệu không ghi được thì sẽ dừng hẳn. "df -h" cho câu trả lời trong một giây, và log cùng bản sao lưu cũ là nơi đầu tiên nên dọn.

Nguyên nhân 3 — Hết kết nối và nguyên nhân 4 — Bảng hỏng

Nếu lỗi chỉ xuất hiện vào giờ cao điểm rồi tự khỏi, bạn đang chạm trần max_connections. Mỗi lượt truy cập chiếm một kết nối, và khi tất cả đã bị chiếm, lượt tiếp theo nhận đúng thông báo lỗi này.

Cám dỗ ở đây là nâng max_connections lên, nhưng mỗi kết nối tốn bộ nhớ nên nâng quá tay chỉ đổi lỗi này lấy lỗi OOM. Cách xử lý bền hơn là bật cache trang để phần lớn lượt xem không chạm tới cơ sở dữ liệu, và tìm truy vấn chậm giữ kết nối lâu hơn cần thiết.

Bảng hỏng có triệu chứng rất khác: phần lớn website vẫn chạy, chỉ một vài trang hoặc một chức năng bị lỗi. Nguyên nhân thường là mất điện hoặc đĩa đầy khi đang ghi.

Với WordPress, thêm dòng define('WP_ALLOW_REPAIR', true); vào wp-config.php rồi mở /wp-admin/maint/repair.php để chạy công cụ sửa có sẵn. Xóa dòng đó ngay sau khi xong, vì trang này không yêu cầu đăng nhập.

Ngoài WordPress, "mysqlcheck --repair --all-databases" làm việc tương tự. Dù dùng cách nào, hãy sao lưu trước khi sửa — công cụ sửa bảng đôi khi phải bỏ đi những bản ghi không cứu được.

Ngăn nó xảy ra lần nữa

• Thêm swap nếu VPS có ít RAM. Đây là thay đổi một lần loại bỏ nguyên nhân phổ biến nhất của sự cố này.
• Bật cache trang. Mỗi lượt xem được phục vụ từ HTML tĩnh là một kết nối cơ sở dữ liệu không bao giờ được tạo ra.
• Theo dõi dung lượng đĩa và cảnh báo ở mức 80%. Đĩa đầy vừa làm dịch vụ dừng vừa gây hỏng bảng, nên một cảnh báo ngăn được hai sự cố.
• Sao lưu tự động hằng ngày và kiểm tra thử việc khôi phục. Bản sao lưu chưa từng được khôi phục thử chỉ là một giả định.
• Giữ thông tin đăng nhập cơ sở dữ liệu ở một chỗ duy nhất. Sự cố này rất hay xảy ra sau khi đổi mật khẩu trong bảng điều khiển mà quên cập nhật file cấu hình.
• Bật slow query log. Truy vấn chậm là gốc rễ chung của cả tình trạng hết kết nối lẫn hết bộ nhớ.