Trong vài năm qua, việc áp dụng PostgreSQL ngày càng tăng. PostgreSQL là một cơ sở dữ liệu quan hệ tuyệt vời. Tính năng khôn ngoan, nó ở đó với những thứ tốt nhất, nếu không phải là tốt nhất. Có nhiều điều tôi yêu thích ở nó - PL / PG SQL, mặc định thông minh, tính năng sao chép (thực sự hoạt động hiệu quả) và một cộng đồng mã nguồn mở năng động và sôi nổi. Tuy nhiên, ngoài các tính năng, có những khía cạnh quan trọng khác của cơ sở dữ liệu cần được xem xét. Nếu bạn đang có kế hoạch xây dựng một cơ sở hoạt động lớn 24/7, thì khả năng vận hành cơ sở dữ liệu một cách dễ dàng ngay khi nó được đưa vào sản xuất sẽ trở thành một yếu tố rất quan trọng. Về khía cạnh này, PostgreSQL không hoạt động tốt lắm. Trong bài đăng trên blog này, chúng tôi sẽ trình bày chi tiết một số thách thức hoạt động này với PostgreSQL. Về cơ bản, không có gì là không thể sửa chữa ở đây, chỉ là một vấn đề về mức độ ưu tiên. Hy vọng rằng chúng tôi có thể tạo ra đủ sự quan tâm trong cộng đồng nguồn mở để ưu tiên các tính năng này.
1. Không phát hiện trình điều khiển máy khách tự động của chuyển đổi dự phòng chính
Trình điều khiển máy khách PostgreSQL không tự động phát hiện khi có một chuyển đổi dự phòng chính (và một chủ mới đã được chọn). Để giải quyết vấn đề này, quản trị viên phải triển khai một lớp proxy ở phía máy chủ. Các lựa chọn phổ biến là ánh xạ DNS, ánh xạ IP ảo, PgPool và HAProxy. Tất cả các tùy chọn này có thể được thực hiện để hoạt động tốt, nhưng cần có một nỗ lực học hỏi và quản trị viên bổ sung đáng kể. Trong trường hợp proxy được đưa vào đường dẫn dữ liệu, cũng có tác động đáng kể đến hiệu suất. Đây là một tính năng tiêu chuẩn được tích hợp sẵn trong nhiều cơ sở dữ liệu NoSQL mới và PostgreSQL sẽ rất hữu ích khi lấy ra khỏi sách của họ khi nói đến hoạt động.
2. Không tích hợp tự động chuyển đổi dự phòng giữa Chế độ chính và Chế độ chờ
Khi một máy chủ PostgreSQL bị lỗi, một trong các máy chủ dự phòng cần được chọn làm máy chủ. Cơ chế này không được tích hợp sẵn trong PostgreSQL. Thông thường, các công cụ phần mềm của bên thứ ba như Patroni, Pacemaker, v.v. được sử dụng để xử lý tình huống này. Tại sao điều này không được tích hợp vào máy chủ? Các công cụ của bên thứ ba này trông có vẻ đơn giản nhưng nó đòi hỏi nỗ lực, kiến thức và thử nghiệm đáng kể từ phía quản trị viên để có được quyền này. Bằng cách xây dựng điều này vào cơ sở dữ liệu, bạn đang thực hiện một sự ủng hộ to lớn đối với người quản trị cơ sở dữ liệu của mình.
Giúp Quản lý Cơ sở dữ liệu Sản xuất #PostgreSQL dễ dàng hơnNhấp vào Tweet3. Không có bản nâng cấp chính nào về thời gian ngừng hoạt động
Không thể nâng cấp cơ sở dữ liệu PostgreSQL của bạn từ phiên bản chính này sang phiên bản chính khác nếu không có thời gian ngừng hoạt động. Về cơ bản, bạn phải tắt tất cả các máy chủ của mình và sử dụng pg_upgrade để nâng cấp dữ liệu của mình lên phiên bản mới hơn. Thời gian chết không lớn vì không có bản sao dữ liệu liên quan, tuy nhiên, vẫn có thời gian chết. Nếu bạn đang hoạt động 24/7, đây có thể không phải là một lựa chọn dành cho bạn.
Với việc phát hành bản sao hợp lý, chúng tôi có một tùy chọn thay thế để nâng cấp trực tuyến.
- Xây dựng thiết lập PostgreSQL Master-Standby hoàn toàn mới với phiên bản mới.
- Thiết lập tính năng sao chép hợp lý để sao chép từ phiên bản cũ sang phiên bản mới hơn.
- Khi bạn đã sẵn sàng, hãy thay đổi chuỗi kết nối của bạn để trỏ từ thiết lập cũ sang thiết lập mới.
Một lần nữa, điều này có thể thành công, nhưng chi phí rất lớn. Lý tưởng nhất, điều cần thiết ở đây là một cách nâng cấp tại chỗ theo kiểu cuốn chiếu qua thiết lập chế độ chờ chính. Nâng cấp MySQL cho phép bạn nâng cấp tại chỗ các nô lệ của mình lên phiên bản mới và sau đó kích hoạt chuyển đổi dự phòng.
4. Không có VACUUM ĐẦY ĐỦ
Autovacuum / VACUUM rất hữu ích và giúp giải quyết vấn đề này ở một mức độ nào đó. Bạn nên thường xuyên kiểm tra độ phồng trên bàn của mình để đảm bảo cài đặt hút chân không phù hợp và hoạt động tốt cho bàn của bạn. Tuy nhiên, autovacuum không hoàn toàn thuận lợi - nó không thực sự kết thúc việc hợp nhất và xóa các trang. Nếu bạn có một số lượng lớn các bản cập nhật, chèn và xóa khối lượng công việc, các trang của bạn sẽ bị phân mảnh, ảnh hưởng đến hiệu suất của bạn. Cách duy nhất để giải quyết vấn đề này là chạy VACUUM FULL, về cơ bản sẽ xây dựng lại tất cả các trang để loại bỏ phân mảnh. Tuy nhiên, quá trình này chỉ có thể được thực hiện với thời gian ngừng hoạt động - bảng của bạn không hoạt động trong khoảng thời gian VACUUM FULL. Đối với các tập dữ liệu lớn, quá trình này có thể mất vài giờ và không phải là một giải pháp thay thế thực tế nếu bạn muốn chạy một hoạt động 24/7.
Lưu ý:Cộng đồng đã bắt đầu làm việc trên công cụ lưu trữ zheap để khắc phục hạn chế này.
Nếu có những cải tiến khác mà bạn cho là hữu ích, vui lòng để lại nhận xét.
