Lỗi Kết Nối Cơ Sở Dữ Liệu WordPress: Cách Khắc Phục

Bạn mở website và mọi trang — cả giao diện ngoài lẫn wp-admin — đều bị thay bằng một câu chữ màu xám duy nhất: Lỗi khi kết nối cơ sở dữ liệu. Không có gì hiển thị, vì không thể hiển thị. WordPress còn chưa kịp dựng đến một trang.

Đây là mô hình tư duy giúp bạn sửa nhanh. WordPress lưu toàn bộ nội dung của bạn — bài viết, trang, thiết lập, người dùng — trong một cơ sở dữ liệu MySQL, chứ không phải trong các tệp. Ở mỗi request, nó đọc bốn thông tin đăng nhập từ wp-config.php, kết nối tới cơ sở dữ liệu đó và lấy ra thứ cần dùng. Lỗi này nghĩa là kết nối ấy đã được thử và bị từ chối. Việc cần làm là tìm ra vì sao nó bị từ chối, và chỉ có ba khả năng.

Ba nguyên nhân, xếp theo mức độ phổ biến

1. Một thông tin đăng nhập sai trong wp-config.php — thường là hậu quả của việc chuyển hosting.
2. Máy chủ cơ sở dữ liệu tắt hoặc quá tải — thường là hậu quả của việc không có gì thay đổi ở phía bạn.
3. Cơ sở dữ liệu bị hỏng — ít gặp hơn, và nó biểu hiện theo cách khác.

Hãy xử lý theo đúng thứ tự đó.

Bước 1: kiểm tra bốn thông tin đăng nhập

Mở wp-config.php ở thư mục gốc của website qua SFTP hoặc trình quản lý tệp của hosting. Bốn dòng định nghĩa kết nối:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Mỗi giá trị này phải khớp chính xác với những gì hosting đã cấp cho bạn. Mở mục cơ sở dữ liệu trong bảng điều khiển hosting (trong cPanel là “MySQL Databases”) và so sánh từng ký tự một:

• DB_NAME — hosting thường thêm tiền tố tên tài khoản vào trước, như cpaneluser_wpdb. Tiền tố đó là một phần của tên.
• DB_USER — quy tắc tiền tố tương tự cũng áp dụng, và người dùng phải được gán vào cơ sở dữ liệu đó, chứ không chỉ tồn tại.
• DB_PASSWORD — thủ phạm phổ biến nhất. Nếu không chắc, hãy đặt lại trong bảng điều khiển và dán giá trị mới vào. Coi chừng một khoảng trắng thừa ở cuối hoặc một dấu nháy cong.
• DB_HOST — đừng mặc định là localhost. Nhiều hosting dùng một máy chủ cơ sở dữ liệu riêng với địa chỉ như mysql.yourhost.com, đôi khi kèm :port. Bảng điều khiển cho thấy giá trị đúng.

Vì chính tệp này là nơi bốn giá trị đó nằm, cách an toàn nhất để tạo lại một wp-config.php sạch và đặt dấu nháy đúng là công cụ tạo wp-config.php — điền bốn trường cơ sở dữ liệu và dán kết quả đè lên khối cũ.

Chỉ riêng bước này đã sửa được lỗi sau gần như mọi lần chuyển hosting, vì thông tin đăng nhập vốn đúng trên hosting cũ lại sai trên hosting mới.

Bước 2: xác nhận máy chủ cơ sở dữ liệu thực sự đang hoạt động

Nếu thông tin đăng nhập đúng mà lỗi vẫn còn — nhất là khi nó tự xuất hiện mà bạn chẳng thay đổi gì — thì nghi phạm chính là bản thân máy chủ cơ sở dữ liệu.

Trên hosting chia sẻ, điều này rất thường gặp và thường chỉ là tạm thời: dịch vụ MySQL bị quá tải trong lúc lưu lượng tăng vọt hoặc chạm giới hạn kết nối của mỗi tài khoản rồi bắt đầu từ chối kết nối mới. Nó thường hồi phục trong vài phút. Hãy chờ một lát rồi tải lại trước khi làm điều gì mạnh tay.

Để kiểm tra xem thông tin đăng nhập có hợp lệ hay không, độc lập với WordPress, hãy đặt một đoạn mã nhỏ bên cạnh wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Dùng đúng DB_HOST, DB_USER và DB_PASSWORD thật của bạn. Nếu nó in ra Connected, thông tin đăng nhập của bạn hoạt động và vấn đề nằm ở chỗ khác (một cơ sở dữ liệu bị hỏng, Bước 3). Nếu nó in ra lỗi kết nối, thông báo sẽ cho biết là lỗi nào: “Access denied” nghĩa là sai người dùng hoặc mật khẩu; “Can’t connect to MySQL server” nghĩa là sai máy chủ hoặc dịch vụ thực sự đang tắt — đã đến lúc liên hệ nhà cung cấp hosting. Xóa đoạn mã ngay khi bạn xong việc.

Bước 3: sửa một cơ sở dữ liệu bị hỏng

Có một dấu hiệu tách hỏng dữ liệu khỏi vấn đề kết nối: giao diện ngoài tải được nhưng wp-admin báo lỗi, hoặc ngược lại. Nếu kết nối thực sự bị từ chối thì cả hai đều chết. Một sự tách biệt như vậy chỉ ra các bảng đã hư hại.

WordPress có sẵn một công cụ sửa chữa. Thêm một dòng vào wp-config.php, phía trên dòng ghi chú “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Rồi truy cập URL này trực tiếp trên trình duyệt của bạn:

https://yoursite.com/wp-admin/maint/repair.php

Nó tải mà không cần đăng nhập — đó chính là mục đích, vì có thể bạn đang bị khóa ngoài — và cung cấp “Repair Database” cùng “Repair and Optimize Database.” Hãy chạy nó.

Rồi lập tức xóa dòng đó khỏi wp-config.php. Khi nó còn đó, bất kỳ ai trên internet cũng có thể mở URL ấy và chạy sửa chữa trên cơ sở dữ liệu của bạn. Đây không phải việc dọn dẹp tùy chọn; đây là bịt một lỗ hổng mà bạn vừa mở ra.

Bước 4: khi trình sửa chữa còn không kết nối được

Nếu chính trang sửa chữa hiển thị lỗi kết nối thì chẳng có gì để sửa — hoàn toàn không thể chạm tới cơ sở dữ liệu, nên bạn quay lại Bước 1 hoặc Bước 2. Ở thời điểm đó, nước đi đáng tin cậy là khôi phục cơ sở dữ liệu từ bản sao lưu gần nhất của nhà cung cấp hosting. Hầu hết bảng điều khiển đều giữ các bản chụp cơ sở dữ liệu hằng ngày tự động; khôi phục từ tối qua gần như luôn nhanh hơn và an toàn hơn việc đuổi theo một sự cố hỏng mà bạn còn không kết nối được.

Những lời khuyên bạn có thể yên tâm bỏ qua

“Cứ cài lại WordPress đi.” Lỗi này là về kết nối cơ sở dữ liệu, không phải tệp lõi. Cài lại chỉ thay thế đúng những tệp đang chạy tốt và không đụng tới bất cứ thứ gì đang hỏng.

“Tăng giới hạn bộ nhớ PHP lên.” Cạn bộ nhớ là một lỗi khác với một thông báo khác. Nâng giới hạn chẳng giúp được gì cho một kết nối cơ sở dữ liệu bị từ chối, chỉ che giấu việc bạn chưa hề kiểm tra thông tin đăng nhập.

“Xóa bộ nhớ đệm đi.” Sự cố xảy ra trong PHP trước khi bất kỳ bộ nhớ đệm nào kịp phục vụ một trang. Xóa bộ nhớ đệm chẳng thay đổi gì khi kết nối còn bị từ chối; chỉ đáng làm sau khi website đã trở lại.

“Sửa trực tiếp cơ sở dữ liệu để khắc phục.” Vội vàng dùng phpMyAdmin để sửa tay các bảng trước khi xác nhận kết nối có hoạt động hay không chính là cách một sự cố tạm thời biến thành mất dữ liệu vĩnh viễn. Xác nhận kết nối trước; động vào dữ liệu sau cùng, và chỉ từ một bản sao lưu.

Vẫn bế tắc?

Nếu thông tin đăng nhập được xác thực bằng đoạn mã kiểm tra, máy chủ đang hoạt động, trình sửa chữa kết nối được và không báo lỗi, nhưng website vẫn hiện thông báo đó, thì nghi phạm còn lại là một plugin nói chuyện với cơ sở dữ liệu qua kết nối riêng của nó — một plugin lưu bộ nhớ đệm hoặc cơ sở dữ liệu đã lưu một địa chỉ máy chủ cũ. Đổi tên wp-content/plugins thành plugins-off qua SFTP để loại trừ khả năng đó. Nếu lỗi biến mất, hãy bật lại từng plugin một cho tới khi nó quay lại.