Mục tiêu chính của thiết lập đa trung tâm dữ liệu (hoặc đa DC) - bất kể hệ sinh thái cơ sở dữ liệu là SQL (PostgreSQL, MySQL) hay NoSQL (MongoDB, Cassandra) hay chỉ một vài cái tên - là Độ trễ thấp đối với người dùng cuối, Tính sẵn sàng cao và phục hồi sau thảm họa. Trọng tâm của một môi trường như vậy là khả năng sao chép dữ liệu, theo những cách đảm bảo độ bền của nó (như một lưu ý phụ là các thông số cấu hình độ bền của Cassandra tương tự như các thông số được sử dụng bởi PostgreSQL). Các yêu cầu sao chép khác nhau sẽ được thảo luận bên dưới, tuy nhiên, các trường hợp cực đoan sẽ được để dành cho những người tò mò nghiên cứu thêm.
Sao chép bằng cách sử dụng vận chuyển nhật ký không đồng bộ đã có sẵn trong PostgreSQL từ lâu và sao chép đồng bộ được giới thiệu trong phiên bản 9.1 đã mở ra một bộ tùy chọn hoàn toàn mới cho các nhà phát triển công cụ quản lý PostgreSQL.
Những điều cần xem xét
Một cách để hiểu sự phức tạp của việc triển khai PostgreSQL multi-DC là học hỏi từ các giải pháp được triển khai cho các hệ thống cơ sở dữ liệu khác, đồng thời lưu ý rằng PostgreSQL nhất quyết tuân thủ ACID.
Trong hầu hết các trường hợp, thiết lập đa DC bao gồm ít nhất một trung tâm dữ liệu trên đám mây. Mặc dù các nhà cung cấp dịch vụ đám mây thay mặt khách hàng của họ gánh vác trách nhiệm quản lý việc nhân rộng cơ sở dữ liệu, nhưng họ thường không phù hợp với các tính năng có sẵn trong các công cụ quản lý chuyên biệt. Ví dụ:với nhiều doanh nghiệp sử dụng các giải pháp đám mây kết hợp và / hoặc đa đám mây, ngoài cơ sở hạ tầng sẵn có trên cơ sở tiền đề của họ, một công cụ đa DC sẽ có thể xử lý môi trường hỗn hợp như vậy.
Hơn nữa, để giảm thiểu thời gian chết trong quá trình chuyển đổi dự phòng, hệ thống quản lý PostgreSQL có thể yêu cầu (thông qua lệnh gọi API) cập nhật DNS, do đó, các yêu cầu cơ sở dữ liệu được chuyển đến cụm chính mới.
Các mạng trải dài các khu vực địa lý rộng lớn là các kết nối có độ trễ cao và tất cả các giải pháp đều phải thỏa hiệp:quên việc sao chép đồng bộ và sử dụng một mạng chính với nhiều bản sao đã đọc. Xem các nghiên cứu AWS MongoDB và Somenines / Galera Cluster để có phân tích chuyên sâu về ảnh hưởng của mạng đối với việc nhân rộng. Trên một lưu ý liên quan, một công cụ tiện lợi để kiểm tra độ trễ giữa các vị trí là Wonder Network Ping Statistics.
Mặc dù không thể thay đổi bản chất độ trễ cao của mạng WAN, nhưng trải nghiệm người dùng có thể được cải thiện đáng kể bằng cách đảm bảo rằng các lần đọc được phân phát từ một bản sao đọc gần với vị trí của người dùng, tuy nhiên có một số lưu ý. Bằng cách di chuyển các bản sao ra khỏi bản chính, việc ghi bị trì hoãn và do đó chúng ta phải loại bỏ bản sao đồng bộ. Giải pháp cũng phải có khả năng giải quyết các vấn đề khác như tính nhất quán đọc-sau-ghi và các lần đọc thứ cấp cũ do mất kết nối.
Để giảm thiểu RTO, dữ liệu cần được sao chép sang một bộ lưu trữ lâu bền cũng có thể cung cấp thông lượng đọc cao và theo Citus Data, một tùy chọn đáp ứng các yêu cầu đó là AWS S3.
Chính khái niệm về nhiều trung tâm dữ liệu ngụ ý rằng hệ thống quản lý cơ sở dữ liệu phải có khả năng trình bày DBA với cái nhìn toàn cầu về tất cả các trung tâm dữ liệu và các cụm PostgreSQL khác nhau bên trong chúng, quản lý nhiều phiên bản PostgreSQL và định cấu hình sao chép giữa chúng.
Khi sao chép ghi tới các trung tâm dữ liệu khu vực, độ trễ lan truyền phải được theo dõi. Nếu độ trễ vượt quá ngưỡng, một cảnh báo sẽ được kích hoạt cho biết rằng bản sao có chứa dữ liệu cũ. Nguyên tắc tương tự cũng áp dụng cho sao chép đa tổng thể không đồng bộ.
Trong một thiết lập đồng bộ, độ trễ cao hoặc gián đoạn mạng có thể dẫn đến sự chậm trễ trong việc cung cấp các yêu cầu của khách hàng trong khi chờ cam kết hoàn thành, trong khi ở các cấu hình không đồng bộ, có nguy cơ bị tách não hoặc giảm hiệu suất trong một thời gian dài. Không thể tránh khỏi sự chậm trễ trong các cam kết đồng bộ ngay cả với các giải pháp sao chép đã được thiết lập tốt như được giải thích trong bài viết Cụm cơ sở dữ liệu phân tán theo địa lý với Galera.
Một cân nhắc khác là hỗ trợ của nhà cung cấp - kể từ khi viết bài này, AWS không hỗ trợ các bản sao giữa các vùng của PostgreSQL.
Hệ thống quản lý thông minh nên giám sát độ trễ của mạng giữa các trung tâm dữ liệu và đề xuất hoặc điều chỉnh các thay đổi, ví dụ:sao chép đồng bộ hoàn toàn ổn giữa các Vùng sẵn sàng của AWS nơi các trung tâm dữ liệu được kết nối bằng mạng cáp quang. Bằng cách đó, một giải pháp có thể không mất dữ liệu và nó cũng có thể thực hiện sao chép tổng thể chủ cùng với cân bằng tải. Lưu ý rằng AWS Aurora PostgreSQL hiện không cung cấp tùy chọn sao chép tổng thể chính.
Quyết định mức độ sao chép:cụm, cơ sở dữ liệu, bảng. Tiêu chí quyết định phải bao gồm chi phí băng thông.
Triển khai sao chép theo tầng để khắc phục sự cố gián đoạn mạng có thể ngăn các bản sao nhận cập nhật từ bản chính do khoảng cách địa lý.
Giải pháp
Xem xét tất cả các yêu cầu để xác định các sản phẩm phù hợp nhất cho công việc. Tuy nhiên, một lưu ý thận trọng:mỗi giải pháp đều có những lưu ý riêng mà bạn phải xử lý bằng cách tuân theo các khuyến nghị trong tài liệu sản phẩm. Xem ví dụ về yêu cầu Giám sát BDR.
Tài liệu chính thức của PostgreSQL chứa danh sách các ứng dụng nguồn mở phi thương mại và danh sách mở rộng bao gồm các giải pháp nguồn đóng thương mại có thể tìm thấy tại trang wiki Replication, Clustering và Connection Pooling. Một số công cụ trong số đó đã được xem xét chi tiết hơn trong bài viết Giải pháp HA phân cụm PG hàng đầu cho PostgreSQL.
Không có giải pháp chìa khóa trao tay, nhưng một số sản phẩm có thể cung cấp hầu hết các tính năng, đặc biệt là khi làm việc với nhà cung cấp.
Đây là danh sách không đầy đủ:
- Citus Data cung cấp bản dựng PostgreSQL của riêng họ, được cải tiến với các tính năng ấn tượng dành cho doanh nghiệp và tích hợp sâu với AWS.
- EnterpriseDB cung cấp một bộ dịch vụ lớn có thể được kết hợp để đáp ứng hầu hết các yêu cầu. Hầu hết thông tin đều có tại Tài liệu sản phẩm.
- Postgres-BDR là một công cụ sao chép mạnh mẽ được thiết kế đặc biệt cho các cụm phân tán theo địa lý, tuy nhiên nó không tích hợp với bất kỳ nhà cung cấp dịch vụ đám mây nào.
- ClusterControl đi kèm với một bộ tính năng ấn tượng- để quản lý PostgreSQL. Nó cũng có giới hạn tích hợp đám mây.
- ElephantSQL hoạt động trên nhiều nhà cung cấp đám mây. Tuy nhiên, không có tùy chọn nào cho thiết lập tại chỗ.
- PostgreSQL giòn cho Kubernetes là một sản phẩm bất khả tri đám mây được xây dựng trên PostgreSQL ngược dòng.
Kết luận
Như chúng ta đã thấy, khi nói đến việc chọn giải pháp đa trung tâm dữ liệu PostgreSQL, không có một giải pháp nào phù hợp với tất cả. Thông thường, thỏa hiệp là điều bắt buộc. Tuy nhiên, việc hiểu rõ các yêu cầu và hàm ý có thể giúp ích rất nhiều trong việc đưa ra quyết định sáng suốt.
So với dữ liệu tĩnh (chỉ đọc), một giải pháp cho cơ sở dữ liệu cần xem xét việc nhân rộng các bản cập nhật (ghi). Tài liệu mô tả cả giải pháp sao chép SQL và NoSQL đều nhấn mạnh vào việc sử dụng một nguồn chân lý duy nhất để ghi với nhiều bản sao nhằm tránh các vấn đề như phân tách não và tính nhất quán đọc sau khi ghi.
Cuối cùng, khả năng tương tác là một yêu cầu quan trọng khi thiết lập đa DC có thể mở rộng các trung tâm dữ liệu đặt tại cơ sở và các nhà cung cấp đám mây khác nhau.
