Thông báo lỗi
Bạn cố gắng kết nối với cơ sở dữ liệu của mình, nhưng thay vì lời nhắc nhập mật khẩu, bạn lại gặp phải thông báo thẳng thừng này:
psql: error: could not connect to server: could not translate host name "db.example.com" to address: Name or service not known
PostgreSQL thực chất không phải là "thủ phạm" ở đây. Lỗi này xuất phát từ ngăn xếp mạng (network stack) của hệ điều hành. Điều đó có nghĩa là hệ thống của bạn đã cố gắng tìm địa chỉ IP cho db.example.com nhưng không có kết quả. Nếu hệ điều hành không thể ánh xạ tên miền sang một địa chỉ IP, kết nối sẽ bị ngắt ngay cả trước khi nó bắt đầu.
Điều gì thường gây ra lỗi?
DNS (Domain Name System) giống như cuốn danh bạ của Internet. Khi bạn cung cấp một hostname cho psql, hệ điều hành phải chuyển đổi nó thành một địa chỉ IP dạng số, chẳng hạn như 10.0.5.42. Nếu quá trình tra cứu đó thất bại, quá trình bắt tay (handshake) sẽ không bao giờ diễn ra.
Hãy kiểm tra các nguyên nhân phổ biến sau:
- Sai sót nhỏ: Gõ sai hostname trong tệp
.envhoặc chuỗi kết nối. - DNS không thể truy cập: Nameserver được cấu hình (như
8.8.8.8) đang bị treo hoặc bị chặn bởi tường lửa. - Cách ly VPN/VPC: Bạn đang cố gắng truy cập một thực thể AWS RDS riêng tư mà không kết nối đúng VPC.
- Thiếu ánh xạ cục bộ: Hostname là một bí danh tùy chỉnh chưa được thêm vào
/etc/hosts. - Cách ly Docker: Container ứng dụng và container cơ sở dữ liệu của bạn không dùng chung một mạng.
Các bước khắc phục
1. Loại trừ lỗi đánh máy
Nghe có vẻ hiển nhiên, nhưng chỉ cần một ký tự đặt sai chỗ cũng sẽ làm hỏng kết nối. Hãy kiểm tra xem có khoảng trắng thừa hay thiếu dấu chấm trong các biến host của bạn không.
# Sai - thiếu một chữ cái
psql -h db.postgre.com -U postgres
# Đúng
psql -h db.postgres.com -U postgres
2. Kiểm tra kết nối thủ công
Đừng đoán mò; hãy xác minh những gì hệ điều hành của bạn thấy. Sử dụng các công cụ mạng tiêu chuẩn để xem host đó có tồn tại hay không. Chạy các lệnh sau từ terminal của bạn:
# Kiểm tra phản hồi cơ bản
ping db.example.com
# Hỏi trực tiếp máy chủ DNS của bạn
nslookup db.example.com
# Lấy toàn bộ dấu vết DNS (tốt nhất để gỡ lỗi)
dig db.example.com
Nếu các lệnh này trả về "NXDOMAIN" hoặc "Name or service not known", thì cấu hình DNS của bạn mới là vấn đề, không phải PostgreSQL.
3. Ép buộc ánh xạ cục bộ trong /etc/hosts
Nếu bạn đang làm việc trên một máy chủ phát triển cục bộ mà không có bản ghi DNS công khai, bạn cần ánh xạ nó một cách thủ công. Việc này sẽ bỏ qua hoàn toàn các máy chủ DNS.
Trên Linux hoặc macOS, mở tệp hosts:
sudo nano /etc/hosts
Thêm IP và hostname vào cuối tệp. Ví dụ: nếu máy chủ của bạn ở địa chỉ 192.168.1.105:
192.168.1.105 db.example.com
Lưu lại và thử kết nối lại. Đây là một cách khắc phục nhanh chóng, nhưng đừng dựa vào nó để mở rộng quy mô sản xuất (production).
4. Sửa chữa bộ phân giải DNS
Nếu máy chủ của bạn không thể phân giải bất kỳ trang web bên ngoài nào, tệp resolv.conf của bạn có thể đang trống hoặc bị hỏng.
cat /etc/resolv.conf
Nếu thiếu các nameserver, bạn có thể tạm thời thêm các địa chỉ đáng tin cậy như Google hoặc Cloudflare để hoạt động trở lại:
nameserver 8.8.8.8
nameserver 1.1.1.1
5. Mạng Docker và Container
Trong Docker, các container thường phân giải lẫn nhau bằng tên dịch vụ của chúng. Nếu container app của bạn không thể thấy container db, có lẽ chúng không nằm trên cùng một mạng ảo.
# Ví dụ đoạn mã docker-compose.yml
services:
db:
image: postgres
networks:
- backend
app:
networks:
- backend
environment:
- DATABASE_URL=postgres://user:pass@db:5432/dbname # 'db' là hostname
Hãy đảm bảo cả hai dịch vụ đều dùng chung một khối mạng trong tệp compose của bạn.
Xác minh việc khắc phục
Sau khi bạn đã điều chỉnh các cài đặt, hãy sử dụng psql với cờ -h để xác nhận kết nối đã thông suốt:
psql -h db.example.com -U your_username -d your_database -W
Nếu bạn thấy lời nhắc Password for user ...: hoặc shell của PostgreSQL (=>), bạn đã vượt qua được rào cản DNS.
Phòng ngừa và các phương pháp hay nhất
Hostname an toàn hơn các IP được mã hóa cứng, nhưng chúng yêu cầu một nền tảng ổn định. Hãy giữ cho mạng của bạn luôn bền bỉ với những mẹo sau:
- Sử dụng DNS được quản lý: Đối với môi trường production, hãy sử dụng AWS Route53 private zones hoặc Cloudflare thay vì các mục nhập
/etc/hostsdễ bị lỗi. - Phát hiện dịch vụ (Service Discovery): Trong Kubernetes, hãy sử dụng tên dịch vụ nội bộ (ví dụ:
db.default.svc.cluster.local) để đảm bảo địa chỉ ổn định ngay cả khi các pod khởi động lại. - Lập kế hoạch mạng con: Lập kế hoạch mạng phù hợp giúp ngăn chặn các vòng lặp định tuyến. Tôi thường sử dụng IP Subnet Calculator để lập bản đồ các dải CIDR một cách chính xác. Điều này đảm bảo các máy chủ DNS và các nút cơ sở dữ liệu của bạn nằm trong các phân đoạn có thể truy cập được, tránh các lỗi "address not known" do các mạng con bị cô lập gây ra.
- Lưu ý về TTL: Nếu bạn vừa di chuyển cơ sở dữ liệu của mình, hãy nhớ rằng các bản ghi DNS có thể mất từ 5 đến 60 phút để cập nhật tùy thuộc vào cài đặt TTL của bạn.