Tôi đã bắt đầu viết về công cụ (pglupgrade) mà tôi đã phát triển để thực hiện nâng cấp tự động gần như bằng không thời gian chết của các cụm PostgreSQL. Trong bài đăng này, tôi sẽ nói về công cụ và thảo luận về các chi tiết thiết kế của nó.
Bạn có thể xem phần đầu tiên của loạt bài này tại đây:Nâng cấp tự động gần như không có thời gian ngừng hoạt động của cụm PostgreSQL trong đám mây (Phần I).
Công cụ này được viết bằng Ansible. Tôi đã có kinh nghiệm làm việc với Ansible trước đây và hiện tại tôi cũng đang làm việc với nó trong 2ndQuadrant, đó là lý do tại sao đó là một lựa chọn thoải mái đối với tôi. Điều đó đang được nói, bạn có thể triển khai logic nâng cấp thời gian chết tối thiểu, sẽ được giải thích ở phần sau của bài đăng này, bằng công cụ tự động hóa yêu thích của bạn.
Đọc thêm:Các bài đăng trên blog Ansible Loves PostgreSQL, PostgreSQL Planet in Ansible Galaxy và trình bày Quản lý PostgreSQL với Ansible.
Pglupgrade Playbook
Trong Ansible, sách chơi là các tập lệnh chính được phát triển để tự động hóa các quy trình như cung cấp các phiên bản đám mây và nâng cấp các cụm cơ sở dữ liệu. Playbook có thể chứa một hoặc nhiều vở kịch . Playbook cũng có thể chứa biến , vai trò và trình xử lý nếu được xác định.
Công cụ này bao gồm hai playbook chính. Playbook đầu tiên là provision.yml tự động hóa quy trình tạo máy Linux trên đám mây, theo các thông số kỹ thuật ( Đây là một cuốn sách phát tùy chọn chỉ được viết để cung cấp các phiên bản đám mây và không liên quan trực tiếp đến việc nâng cấp ). Playbook thứ hai (và chính) là pglupgrade.yml tự động hóa quá trình nâng cấp của các cụm cơ sở dữ liệu.
Sách chơi Pglupgrade có tám lượt chơi để sắp xếp việc nâng cấp. Mỗi lần phát, sử dụng một tệp cấu hình (config.yml ), thực hiện một số tác vụ trên máy chủ hoặc nhóm máy chủ được xác định trong tệp khoảng không quảng cáo trên máy chủ lưu trữ (host.ini ).
Tệp Kiểm kê
Tệp kiểm kê cho phép Ansible biết máy chủ nào nó cần kết nối bằng SSH, thông tin kết nối mà nó yêu cầu và tùy chọn biến nào được liên kết với các máy chủ đó. Dưới đây, bạn có thể thấy tệp kiểm kê mẫu, đã được sử dụng để thực hiện nâng cấp cụm tự động cho một trong các nghiên cứu điển hình được thiết kế cho công cụ. Chúng ta sẽ thảo luận về các nghiên cứu điển hình này trong các bài đăng sắp tới của loạt bài này.
[old-primary] 54.171.211.188 [new-primary] 54.246.183.100 [old-standbys] 54.77.249.81 54.154.49.180 [new-standbys:children] old-standbys [pgbouncer] 54.154.49.180
Tệp khoảng không quảng cáo (host.ini )
Tệp khoảng không quảng cáo mẫu chứa năm máy chủ lưu trữ dưới năm nhóm máy chủ bao gồm old-primary , new-primary , old-standbys , new-standbys và pgbouncer . Một máy chủ có thể thuộc về nhiều nhóm. Ví dụ:old-standbys là một nhóm chứa new-standbys nhóm, có nghĩa là các máy chủ được xác định theo old-standbys nhóm (54.77.249.81 và 54.154.49.180) cũng thuộc về new-standbys tập đoàn. Nói cách khác, new-standbys nhóm được kế thừa từ (con của) old-standbys tập đoàn. Điều này đạt được bằng cách sử dụng :children đặc biệt hậu tố.
Khi tệp kiểm kê đã sẵn sàng, Ansible playbook có thể chạy qua ansible-playbook bằng cách trỏ đến tệp kiểm kê (nếu tệp kiểm kê không được đặt ở vị trí mặc định nếu không nó sẽ sử dụng tệp kiểm kê mặc định) như hình dưới đây:
$ ansible-playbook -i hosts.ini pglupgrade.yml
Chạy playbook Ansible
Tệp cấu hình
Playbook pglupgrade sử dụng tệp cấu hình (config.yml ) cho phép người dùng chỉ định giá trị cho các biến nâng cấp logic.
Như được hiển thị bên dưới, config.yml chủ yếu lưu trữ các biến dành riêng cho PostgreSQL được yêu cầu để thiết lập một cụm PostgreSQL, chẳng hạn như postgres_old_datadir và postgres_new_datadir để lưu trữ đường dẫn của thư mục dữ liệu PostgreSQL cho các phiên bản PostgreSQL cũ và mới; postgres_new_confdir để lưu trữ đường dẫn của thư mục cấu hình PostgreSQL cho phiên bản PostgreSQL mới; postgres_old_dsn và postgres_new_dsn để lưu trữ chuỗi kết nối cho pglupgrade_user để có thể kết nối với pglupgrade_database của máy chủ chính mới và cũ. Bản thân chuỗi kết nối bao gồm các biến có thể định cấu hình để người dùng (pglupgrade_user ) và cơ sở dữ liệu (pglupgrade_database ) thông tin có thể được thay đổi cho các trường hợp sử dụng khác nhau.
ansible_user: admin
pglupgrade_user: pglupgrade
pglupgrade_pass: pglupgrade123
pglupgrade_database: postgres
replica_user: postgres
replica_pass: ""
pgbouncer_user: pgbouncer
postgres_old_version: 9.5
postgres_new_version: 9.6
subscription_name: upgrade
replication_set: upgrade
initial_standbys: 1
postgres_old_dsn: "dbname={{pglupgrade_database}} host={{groups['old-primary'][0]}} user {{pglupgrade_user}}"
postgres_new_dsn: "dbname={{pglupgrade_database}} host={{groups['new-primary'][0]}} user={{pglupgrade_user}}"
postgres_old_datadir: "/var/lib/postgresql/{{postgres_old_version}}/main"
postgres_new_datadir: "/var/lib/postgresql/{{postgres_new_version}}/main"
postgres_new_confdir: "/etc/postgresql/{{postgres_new_version}}/main" Tệp cấu hình (config.yml )
Là một bước quan trọng cho bất kỳ nâng cấp nào, thông tin phiên bản PostgreSQL có thể được chỉ định cho phiên bản hiện tại (postgres_old_version ) và phiên bản sẽ được nâng cấp lên (postgres_new_version ). Trái ngược với sao chép vật lý trong đó sao chép là bản sao của hệ thống ở cấp byte / khối, sao chép lôgic cho phép sao chép có chọn lọc trong đó bản sao có thể sao chép dữ liệu lôgic bao gồm các cơ sở dữ liệu được chỉ định và các bảng trong các cơ sở dữ liệu đó. Vì lý do này, config.yml cho phép định cấu hình cơ sở dữ liệu nào sẽ sao chép qua pglupgrade_database Biến đổi. Ngoài ra, người dùng sao chép hợp lý cần có đặc quyền sao chép, đó là lý do tại sao pglupgrade_user biến phải được chỉ định trong tệp cấu hình. Có các biến khác có liên quan đến hoạt động bên trong của pglogical chẳng hạn như subscription_name và replication_set được sử dụng trong vai trò y học.
Thiết kế sẵn có cao của Công cụ Pglupgrade
Công cụ Pglupgrade được thiết kế để mang lại sự linh hoạt về thuộc tính Tính sẵn sàng cao (HA) cho người dùng đối với các yêu cầu hệ thống khác nhau. initial_standbys biến (xem config.yml ) là chìa khóa để chỉ định thuộc tính HA của cụm trong khi hoạt động nâng cấp đang diễn ra.
Ví dụ:if initial_standbys được đặt thành 1 (có thể được đặt thành bất kỳ số nào mà dung lượng cụm cho phép), điều đó có nghĩa là sẽ có 1 chế độ chờ được tạo trong cụm được nâng cấp cùng với cái chính trước khi bắt đầu sao chép. Nói cách khác, nếu bạn có 4 máy chủ và bạn đặt Initial_standbys thành 1, bạn sẽ có 1 máy chủ chính và 1 máy chủ dự phòng trong phiên bản mới được nâng cấp, cũng như 1 máy chủ chính và 1 máy chủ dự phòng trong phiên bản cũ.
Tùy chọn này cho phép sử dụng lại các máy chủ hiện có trong khi quá trình nâng cấp vẫn đang diễn ra. Trong ví dụ về 4 máy chủ, máy chủ chính và máy chủ dự phòng cũ có thể được xây dựng lại thành 2 máy chủ dự phòng mới sau khi quá trình nhân bản kết thúc.
Khi initial_standbys biến được đặt thành 0, sẽ không có máy chủ dự phòng ban đầu nào được tạo trong cụm mới trước khi bắt đầu sao chép.
Nếu initial_standbys cấu hình nghe có vẻ khó hiểu, đừng lo lắng. Điều này sẽ được giải thích rõ hơn trong bài đăng blog tiếp theo khi chúng ta thảo luận về hai nghiên cứu điển hình khác nhau.
Cuối cùng, tệp cấu hình cho phép chỉ định nhóm máy chủ cũ và mới. Điều này có thể được cung cấp theo hai cách. Đầu tiên, nếu có một cụm hiện có, địa chỉ IP của máy chủ ( có thể là máy chủ ảo hoặc máy chủ ảo ) phải được nhập vào hosts.ini bằng cách xem xét các thuộc tính HA mong muốn trong khi nâng cấp.
Cách thứ hai là chạy provision.yml playbook ( đây là cách tôi cấp phép các phiên bản đám mây nhưng bạn có thể sử dụng tập lệnh cấp phép của riêng mình hoặc các phiên bản cung cấp theo cách thủ công ) để cung cấp các máy chủ Linux trống trên đám mây (phiên bản AWS EC2) và lấy địa chỉ IP của máy chủ vào hosts.ini tập tin. Dù bằng cách nào, config.yml sẽ nhận được thông tin máy chủ thông qua hosts.ini tệp.
Quy trình làm việc của Quy trình nâng cấp
Sau khi giải thích tệp cấu hình (config.yml ) được sử dụng bởi pglupgrade playbook, chúng tôi có thể giải thích quy trình làm việc của quá trình nâng cấp.
Pglupgrade Workflow
Như được thấy từ sơ đồ trên, có sáu nhóm máy chủ được tạo ngay từ đầu dựa trên cấu hình (cả hosts.ini và config.yml ). new-primary và old-primary các nhóm sẽ luôn có một máy chủ, pgbouncer nhóm có thể có một hoặc nhiều máy chủ và tất cả các nhóm dự phòng có thể không có hoặc nhiều máy chủ trong đó. Thực hiện khôn ngoan, toàn bộ quá trình được chia thành tám bước. Mỗi bước tương ứng với một lần chơi trong sách phát pglupgrade, thực hiện các nhiệm vụ bắt buộc trên các nhóm máy chủ được chỉ định. Quá trình nâng cấp được giải thích thông qua các lần phát sau:
- Tạo máy chủ dựa trên cấu hình: Chơi chuẩn bị xây dựng các nhóm máy chủ nội bộ dựa trên cấu hình. Kết quả của lần chơi này (kết hợp với
hosts.ininội dung) là sáu nhóm máy chủ (được minh họa bằng các màu khác nhau trong sơ đồ quy trình làm việc) sẽ được sử dụng bởi bảy lần phát sau đây. - Thiết lập cụm mới với (các) chế độ chờ ban đầu: Thiết lập một cụm PostgreSQL trống với (các) chế độ chờ ban đầu và chính mới (nếu có bất kỳ điều kiện nào được xác định). Nó đảm bảo rằng không còn lại gì từ các bản cài đặt PostgreSQL từ lần sử dụng trước.
- Sửa đổi chính cũ để hỗ trợ sao chép hợp lý: Cài đặt tiện ích mở rộng pglogical. Sau đó, thiết lập nhà xuất bản bằng cách thêm tất cả các bảng và chuỗi vào bản sao.
- Sao chép sang trang chính mới: Thiết lập người đăng ký trên cái chính mới hoạt động như một trình kích hoạt để bắt đầu sao chép hợp lý. Lần chơi này kết thúc việc sao chép dữ liệu hiện có và bắt đầu bắt kịp những gì đã thay đổi kể từ khi bắt đầu sao chép.
- Chuyển pgbouncer (và các ứng dụng) sang chính mới: Khi độ trễ sao chép hội tụ về 0, hãy tạm dừng pgbouncer để chuyển đổi ứng dụng dần dần. Sau đó, nó trỏ cấu hình pgbouncer đến cấu hình chính mới và đợi cho đến khi sự khác biệt về bản sao bằng không. Cuối cùng, pgbouncer được tiếp tục và tất cả các giao dịch đang chờ được truyền sang giao dịch chính mới và bắt đầu xử lý ở đó. Các dự phòng ban đầu đã được sử dụng và trả lời các yêu cầu đọc.
- Xóa thiết lập sao chép giữa chính cũ và chính mới: Chấm dứt kết nối giữa máy chủ chính cũ và mới. Vì tất cả các ứng dụng được chuyển đến máy chủ chính mới và quá trình nâng cấp đã hoàn tất, nên việc sao chép hợp lý không còn cần thiết nữa. Quá trình sao chép giữa máy chủ chính và máy chủ dự phòng được tiếp tục với quá trình sao chép vật lý.
- Dừng cụm cũ: Dịch vụ Postgres bị dừng trên các máy chủ cũ để đảm bảo không ứng dụng nào có thể kết nối với nó nữa.
- Định cấu hình lại phần còn lại của các standby cho chính mới: Xây dựng lại các standby khác nếu có bất kỳ máy chủ nào còn lại ngoài các standby ban đầu. Trong trường hợp nghiên cứu thứ hai, không có máy chủ dự phòng nào còn lại để xây dựng lại. Bước này mang lại cơ hội xây dựng lại máy chủ chính cũ làm chế độ chờ mới nếu được trỏ trong nhóm chế độ chờ mới tại hosts.ini. Khả năng tái sử dụng của các máy chủ hiện có (ngay cả máy chủ cũ) đạt được bằng cách sử dụng thiết kế cấu hình dự phòng hai bước của công cụ pglupgrade. Người dùng có thể chỉ định máy chủ nào sẽ trở thành máy chủ dự phòng của cụm mới trước khi nâng cấp và máy chủ nào sẽ trở thành máy chủ dự phòng sau khi nâng cấp.
Kết luận
Trong bài đăng này, chúng tôi đã thảo luận về chi tiết triển khai và thiết kế tính khả dụng cao của công cụ pglupgrade. Khi làm như vậy, chúng tôi cũng đã đề cập đến một số khái niệm chính về phát triển Ansible (tức là sách phát, tệp hàng tồn kho và tệp cấu hình) bằng cách sử dụng công cụ này làm ví dụ. Chúng tôi đã minh họa quy trình làm việc của quá trình nâng cấp và tóm tắt cách hoạt động của từng bước với một cách chơi tương ứng. Chúng tôi sẽ tiếp tục giải thích về pglupgrade bằng cách hiển thị các nghiên cứu điển hình trong các bài đăng sắp tới của loạt bài này.
Cảm ơn vì đã đọc!
