PostgreSQL là một dự án tuyệt vời và nó phát triển với tốc độ đáng kinh ngạc. Chúng tôi sẽ tập trung vào sự phát triển của khả năng chịu lỗi trong PostgreSQL trong suốt các phiên bản của nó với một loạt bài đăng trên blog. Đây là bài đăng thứ hai của loạt bài này và chúng ta sẽ nói về nhân bản và tầm quan trọng của nó đối với khả năng chịu lỗi và độ tin cậy của PostgreSQL.
Nếu bạn muốn chứng kiến tiến trình phát triển ngay từ đầu, vui lòng kiểm tra bài đăng trên blog đầu tiên của loạt bài:Tiến hóa về khả năng chịu lỗi trong PostgreSQL
Bản sao PostgreSQL
Sao chép cơ sở dữ liệu là thuật ngữ chúng tôi sử dụng để mô tả công nghệ được sử dụng để duy trì bản sao của một tập hợp dữ liệu trên điều khiển từ xa hệ thống. Giữ một bản sao đáng tin cậy của một hệ thống đang chạy là một trong những mối quan tâm lớn nhất về dự phòng và tất cả chúng ta đều thích các bản sao dữ liệu có thể bảo trì, dễ sử dụng và ổn định.
Hãy xem kiến trúc cơ bản. Thông thường, các máy chủ cơ sở dữ liệu riêng lẻ được gọi là nút . Toàn bộ nhóm máy chủ cơ sở dữ liệu tham gia vào quá trình sao chép được gọi là cụm . Máy chủ cơ sở dữ liệu cho phép người dùng thực hiện thay đổi được gọi là máy chủ hoặc chính , hoặc có thể được mô tả như một nguồn thay đổi. Máy chủ cơ sở dữ liệu chỉ cho phép truy cập chỉ đọc được gọi là Chế độ chờ nóng . ( Thuật ngữ Chế độ chờ nóng được giải thích chi tiết trong tiêu đề Chế độ chờ. )
Khía cạnh quan trọng của sao chép là các thay đổi dữ liệu được ghi lại trên một cái chính, và sau đó được chuyển đến các nút khác. Trong một số trường hợp, một nút có thể gửi các thay đổi dữ liệu đến các nút khác, quá trình này được gọi là phân tầng hoặc chuyển tiếp . Do đó, nút chính là một nút gửi nhưng không phải tất cả các nút gửi đều cần phải là nút chính. Sao chép thường được phân loại theo việc có cho phép nhiều hơn một nút chính hay không, trong trường hợp đó, nó sẽ được gọi là sao chép đa quản trị viên .
Hãy xem cách PostgreSQL xử lý việc sao chép theo thời gian và phương pháp tối tân để chịu lỗi theo các điều khoản sao chép.
Lịch sử sao chép PostgreSQL
Trong lịch sử (khoảng năm 2000-2005), Postgres chỉ tập trung vào khả năng chịu lỗi / khôi phục nút đơn, điều mà hầu hết đạt được bằng WAL, nhật ký giao dịch. Khả năng chịu lỗi được xử lý một phần bởi MVCC (hệ thống đồng thời nhiều phiên bản), nhưng chủ yếu là tối ưu hóa.
Ghi nhật ký ghi trước đã và vẫn là phương pháp chịu lỗi lớn nhất trong PostgreSQL. Về cơ bản, chỉ cần có các tệp WAL nơi bạn viết mọi thứ và có thể khôi phục nếu bị lỗi bằng cách phát lại chúng. Điều này là đủ cho các kiến trúc nút đơn và sao chép được coi là giải pháp tốt nhất để đạt được khả năng chịu lỗi với nhiều nút.
Cộng đồng Postgres từ lâu đã tin rằng sao chép là thứ mà Postgres không nên cung cấp và nên được xử lý bởi các công cụ bên ngoài, đây là lý do tại sao các công cụ như Slony và Londiste trở nên tồn tại. ( Chúng tôi sẽ đề cập đến các giải pháp sao chép dựa trên trình kích hoạt trong các bài đăng blog tiếp theo của loạt bài này.)
Cuối cùng thì rõ ràng là không đủ khả năng chịu đựng của một máy chủ và nhiều người yêu cầu khả năng chịu lỗi thích hợp của phần cứng và cách chuyển đổi phù hợp, một cái gì đó được tích hợp sẵn trong Postgres. Đây là lúc bản sao vật lý (sau đó là phát trực tuyến vật lý) trở nên sống động.
Chúng ta sẽ xem xét tất cả các phương pháp sao chép ở phần sau của bài đăng nhưng chúng ta hãy xem các sự kiện theo trình tự thời gian của lịch sử sao chép PostgreSQL theo các bản phát hành chính:
- PostgreSQL 7.x (~ 2000)
- Bản sao không nên là một phần của Postgres cốt lõi
- Londiste - Slony (sao chép lôgic dựa trên trình kích hoạt)
- PostgreSQL 8.0 (2005)
- Khôi phục theo thời gian (WAL)
- PostgreSQL 9.0 (2010)
- Nhân rộng phát trực tuyến (vật lý)
- PostgreSQL 9.4 (2014)
- Giải mã lôgic (trích xuất bộ thay đổi)
Tái tạo vật lý
PostgreSQL đã giải quyết nhu cầu nhân bản cốt lõi với những gì hầu hết các cơ sở dữ liệu quan hệ làm; đã lấy WAL và có thể gửi nó qua mạng. Sau đó, các tệp WAL này được áp dụng vào một phiên bản Postgres riêng biệt đang chạy ở chế độ chỉ đọc.
Phiên bản chờ chỉ đọc chỉ áp dụng các thay đổi (bởi WAL) và hoạt động ghi duy nhất đến lại từ cùng một nhật ký WAL. Về cơ bản đây là cách sao chép phát trực tuyến cơ chế hoạt động. Ban đầu, bản sao ban đầu là vận chuyển tất cả các tệp - log shipping- , nhưng sau đó nó đã phát triển thành phát trực tuyến.
Trong quá trình vận chuyển nhật ký, chúng tôi đang gửi toàn bộ tệp qua archive_command . Logic khá đơn giản ở đó:bạn chỉ cần gửi kho lưu trữ và nhật ký nó đến một nơi nào đó - như toàn bộ tệp WAL 16MB - và sau đó bạn áp dụng nó đến một nơi nào đó và sau đó bạn tìm nạp tiếp theo và áp dụng cái đó và nó diễn ra như vậy. Sau đó, nó đã phát trực tuyến qua mạng bằng cách sử dụng giao thức libpq trong PostgreSQL phiên bản 9.0.
Bản sao hiện có được gọi đúng hơn là Bản sao truyền trực tuyến vật lý, vì chúng tôi đang phát trực tuyến một loạt các thay đổi vật lý từ nút này sang nút khác. Điều đó có nghĩa là khi chúng tôi chèn một hàng vào một bảng mà chúng tôi tạo thay đổi bản ghi cho chèn cộng với tất cả mục nhập chỉ mục .
Khi chúng ta VACUUM một bảng chúng tôi cũng tạo các bản ghi thay đổi.
Ngoài ra, Bản sao truyền trực tuyến vật lý ghi lại tất cả các thay đổi ở mức byte / khối , khiến bạn rất khó làm bất cứ điều gì khác ngoài việc chỉ phát lại mọi thứ
Hình 1 Tái tạo vật lý
Hình 1 cho thấy cách nhân rộng vật lý hoạt động chỉ với hai nút. Máy khách thực hiện các truy vấn trên nút chính, các thay đổi được ghi vào nhật ký giao dịch (WAL) và được sao chép qua mạng sang WAL trên nút chờ. Sau đó, quá trình khôi phục trên nút chờ sẽ đọc các thay đổi từ WAL và áp dụng chúng cho các tệp dữ liệu giống như trong quá trình khôi phục sự cố. Nếu chế độ chờ ở chế độ chờ nóng , máy khách có thể đưa ra các truy vấn chỉ đọc trên nút trong khi điều này đang xảy ra.
Lưu ý: Sao chép vật lý chỉ đơn giản là gửi các tệp WAL qua mạng từ nút chính đến nút dự phòng. Các tệp có thể được gửi bằng các giao thức khác nhau như scp, rsync, ftp… Sự khác biệt giữa Tái tạo vật lý và Sao chép phát trực tuyến vật lý là Sao chép trực tuyến sử dụng giao thức nội bộ để gửi tệp WAL ( người gửi và quy trình người nhận )
Chế độ chờ
Nhiều nút cung cấp Tính khả dụng cao. Vì lý do đó, các kiến trúc hiện đại thường có các nút dự phòng. Có các chế độ khác nhau cho các nút chờ (chế độ chờ ấm và nóng). Danh sách dưới đây giải thích sự khác biệt cơ bản giữa các chế độ chờ khác nhau và cũng cho thấy trường hợp của kiến trúc đa tổng thể.
Chế độ chờ ấm
Có thể được kích hoạt ngay lập tức, nhưng không thể thực hiện công việc hữu ích cho đến khi được kích hoạt. Nếu chúng tôi liên tục cung cấp loạt tệp WAL cho một máy khác đã được tải cùng tệp sao lưu cơ sở, chúng tôi có một hệ thống chờ ấm:tại bất kỳ thời điểm nào chúng tôi có thể khởi động máy thứ hai và nó sẽ có một bản sao gần như hiện tại của kho dữ liệu. Chế độ chờ ấm không cho phép các truy vấn chỉ đọc, Hình 2 chỉ đơn giản là đại diện cho thực tế này.
Hình 2 Chế độ chờ ấm áp
Hiệu suất phục hồi của chế độ chờ ấm đủ tốt đến mức chế độ chờ thường chỉ diễn ra trong tích tắc sau khi nó được kích hoạt. Do đó, đây được gọi là cấu hình ở chế độ chờ ấm mang lại tính khả dụng cao.
Chế độ chờ nóng
Chế độ chờ nóng là thuật ngữ dùng để mô tả khả năng kết nối với máy chủ và chạy các truy vấn chỉ đọc trong khi máy chủ đang ở chế độ chờ hoặc khôi phục kho lưu trữ. Điều này hữu ích cho cả mục đích sao chép và khôi phục bản sao lưu về trạng thái mong muốn với độ chính xác cao.
<
- Chế độ chờ nóng
Thuật ngữ chế độ chờ nóng cũng đề cập đến khả năng máy chủ chuyển từ trạng thái khôi phục sang hoạt động bình thường trong khi người dùng tiếp tục chạy các truy vấn và / hoặc giữ cho kết nối của họ mở. Hình 3 cho thấy rằng chế độ chờ cho phép các truy vấn chỉ đọc.
Multi-Master
Tất cả các nút đều có thể thực hiện công việc đọc / ghi. (Chúng tôi sẽ đề cập đến kiến trúc đa tổng thể trong các bài đăng blog tiếp theo của loạt bài này.)
Thông số mức WAL
Có một mối quan hệ giữa việc thiết lập
wal_leveltrong tệp postgresql.conf và cài đặt này phù hợp với mục đích gì. Tôi đã tạo một bảng để hiển thị mối quan hệ cho PostgreSQL phiên bản 9.6.
Chuyển đổi dự phòng và chuyển mạch
Trong sao chép một bản cái, nếu bản cái chết, một trong các điểm chờ phải thế chỗ ( khuyến mãi ). Nếu không, chúng tôi sẽ không thể chấp nhận các giao dịch ghi mới. Do đó, thuật ngữ chỉ định, chính và dự phòng, chỉ là những vai trò mà bất kỳ nút nào cũng có thể đảm nhận tại một số thời điểm. Để di chuyển vai trò chính sang một nút khác, chúng tôi thực hiện một thủ tục có tên là Chuyển mạch .
Nếu chủ nhân chết và không phục hồi, thì sự thay đổi vai trò nghiêm trọng hơn được gọi là Chuyển đổi dự phòng . Theo nhiều cách, những điều này có thể tương tự nhau, nhưng sẽ hữu ích khi sử dụng các thuật ngữ khác nhau cho từng sự kiện. (Biết các điều khoản của chuyển đổi dự phòng và chuyển đổi sẽ giúp chúng tôi hiểu các vấn đề về dòng thời gian ở bài đăng blog tiếp theo.)
Kết luận
Trong bài đăng trên blog này, chúng tôi đã thảo luận về việc nhân rộng PostgreSQL và tầm quan trọng của nó trong việc cung cấp khả năng chịu lỗi và độ tin cậy. Chúng tôi đã đề cập đến tính năng Nhân rộng luồng vật lý và nói về Chế độ chờ cho PostgreSQL. Chúng tôi đã đề cập đến Chuyển đổi dự phòng và Chuyển mạch. Chúng tôi sẽ tiếp tục với các mốc thời gian của PostgreSQL ở bài đăng blog tiếp theo.
Tài liệu tham khảo
Tài liệu PostgreSQL
Logical Replication trong PostgreSQL 5432… Bài thuyết trình MeetUs của Petr Jelinek
Sách nấu ăn quản trị PostgreSQL 9 - Phiên bản thứ hai
