PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Chuyển đổi / Chuyển lại trong Slony-I trong khi nâng cấp các phiên bản chính của PostgreSQL 8.4.x / 9.3.x

Mỗi bản phát hành mới của PostgreSQL đều đi kèm với một loạt các tính năng thú vị. Để có lợi cho các tính năng mới, máy chủ cơ sở dữ liệu nên được nâng cấp. Việc chọn các đường dẫn nâng cấp truyền thống như pg_dump / pg_restore hoặc pg_upgrade đòi hỏi thời gian dừng ứng dụng đáng kể. Ngày nay, nếu bạn đang tìm kiếm đường dẫn nâng cấp thời gian chết tối thiểu giữa các phiên bản PostgreSQL chính với kế hoạch khôi phục hoàn hảo, thì nó sẽ được thực hiện bằng cách nhân rộng Slony-I không đồng bộ. Vì Slony-I (biết thêm về nó tại đây) có khả năng sao chép giữa các phiên bản PostgreSQL khác nhau, hệ điều hành và kiến ​​trúc bit một cách dễ dàng, vì vậy có thể thực hiện nâng cấp mà không yêu cầu thời gian ngừng hoạt động đáng kể. Ngoài ra, nó có chức năng chuyển đổi và chuyển đổi nhất quán trong thiết kế của nó.

IMO, trong khi thực hiện các nâng cấp phiên bản lớn, cần có một kế hoạch dự phòng thích hợp vì chỉ trong trường hợp ứng dụng gặp lỗi hoặc không hoạt động tốt trên phiên bản nâng cấp, thì chúng tôi sẽ có thể khôi phục về phiên bản cũ hơn ngay lập tức. Slony-I cung cấp chức năng như vậy theo cách chuyển đổi ngược lại. Bài đăng này chứng minh, nâng cấp thời gian chết tối thiểu bao gồm các bước chuyển đổi / chuyển đổi.

Trước khi đi đến bản demo, một bước quan trọng cần được lưu ý, các cột loại dữ liệu bytea phiên bản PG 9.0.x trước đó sử dụng để lưu trữ dữ liệu ở định dạng ESCAPE và phiên bản sau của nó ở định dạng HEX. Trong khi thực hiện chuyển đổi (phiên bản mới hơn sang phiên bản cũ hơn), loại khác biệt định dạng bytea này không được Slony-I hỗ trợ, do đó định dạng ESCAPE sẽ được duy trì trong suốt thời gian nâng cấp, nếu không bạn có thể gặp phải lỗi:

ERROR  remoteWorkerThread_1_1: error at end of COPY IN: ERROR:  invalid input syntax for type bytea
CONTEXT: COPY sl_log_1, line 1: "1 991380 1 100001 public foo I 0 {id,500003,name,"A ",b,"\\x41"}"
ERROR remoteWorkerThread_1: SYNC aborted

Để khắc phục, không yêu cầu thay đổi trên PG 8.4.x nhưng trên PG 9.3.5 tham số bytea_output nên được đặt từ HEX thành ESCAPE như hình minh họa. Chúng ta có thể đặt nó ở cấp độ cụm ($ PGDATA / postgresql.conf) hoặc cấp độ người dùng (ALTER TABLE… SET), tôi muốn thực hiện với các thay đổi ở cấp độ người dùng.

slavedb=# alter user postgres set bytea_output to escape;
ALTER ROLE

Hãy tiến hành các bước nâng cấp. Dưới đây là chi tiết máy chủ hai phiên bản của tôi được sử dụng trong bản demo này, hãy thay đổi nó cho phù hợp theo thiết lập máy chủ của bạn nếu bạn đang thử:

Origin Node (Master/Primary are called as Origin)                     Subscriber Node (Slave/Secondary are called as Subscriber)
------------------------------------------------- ----------------------------------------------------------
Host IP : 192.168.22.130 192.168.22.131
OS Version : RHEL 6.5 64 bit RHEL 6.5 64 bit
PG Version : 8.4.22 (5432 Port) 9.3.5 (5432 Port)
Slony Vers. : 2.2.2 2.2.2
PG Binaries : /usr/local/pg84/bin /opt/PostgreSQL/9.3/
Database : masterdb slavedb
PK Table : foo(id int primary key, name char(20), image bytea) ...restore PK tables structure from Origin...

Để dễ hiểu và dễ thực hiện, tôi đã chia demo thành ba phần

1. Biên dịch cho các tệp nhị phân Slony-I dựa trên các phiên bản PostgreSQL
2. Tạo tập lệnh sao chép và thực thi
3. Thử nghiệm Chuyển mạch / Chuyển lại.

1. Biên dịch cho các tệp nhị phân Slony-I dựa trên phiên bản PostgreSQL
Tải xuống các nguồn Slony-I từ đây và thực hiện cài đặt nguồn dựa trên các tệp nhị phân PostgreSQL trên các nút Nguồn gốc và Người đăng ký.

On Origin Node:
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgbindir=/usr/local/pg84/bin
--with-pglibdir=/usr/local/pg84/lib
--with-pgincludedir=/usr/local/pg84/include
--with-pgpkglibdir=/usr/local/pg84/lib/postgresql
--with-pgincludeserverdir=/usr/local/pg84/include/postgresql/
make
make install

On Subscriber Node: (assuming PG 9.3.5 installed)
# tar -xvf slony1-2.2.2.tar.bz2
# cd slony1-2.2.2
./configure --with-pgconfigdir=/opt/PostgreSQL/9.3/bin
--with-pgbindir=/opt/PostgreSQL/9.3/bin
--with-pglibdir=/opt/PostgreSQL/9.3/lib
--with-pgincludedir=/opt/PostgreSQL/9.3/include
--with-pgpkglibdir=/opt/PostgreSQL/9.3/lib/postgresql
--with-pgincludeserverdir=/opt/PostgreSQL/9.3/include/postgresql/server/
--with-pgsharedir=/opt/PostgreSQL/9.3/share
make
make install

2. Tạo Tập lệnh sao chép và thực thi
Để thiết lập sao chép, chúng ta cần tạo một vài tập lệnh có chức năng sao chép bao gồm chuyển đổi / chuyển đổi.

1. initialize.slonik - Tập lệnh này chứa thông tin kết nối các nút Nguồn gốc / Người đăng ký.
2. create_set.slonik - Tập lệnh này giữ tất cả các Bảng PK gốc sao chép sang Nút người đăng ký.
3. subscribe_set.slonik - Tập lệnh này bắt đầu sao chép bộ dữ liệu thành Nút người đăng ký.
4. switchhover.slonik - Tập lệnh này giúp chuyển quyền điều khiển từ Nguồn gốc sang Người đăng ký.
5. switchback.slonik - Tập lệnh này giúp kiểm soát dự phòng từ Người đăng ký đến Nguồn gốc.

Cuối cùng, hai tập lệnh khởi động khác “start_OriginNode.sh” “start_SubscriberNode.sh” bắt đầu xử lý slon theo các mã nhị phân được biên dịch trên Nguồn gốc / Nút người đăng ký.

Tải xuống tất cả các tập lệnh từ đây.

Đây là dữ liệu mẫu về Nút gốc (8.4.22) trong Bảng Foo với một cột kiểu dữ liệu bytea, chúng tôi sẽ sao chép dữ liệu đó sang Nút đăng ký (9.3.5) với sự trợ giúp của các tập lệnh được tạo.

masterdb=# select * from foo;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
(3 rows)

Cho phép gọi lần lượt các tập lệnh để thiết lập sao chép. HÃY NHỚ TẤT CẢ KHOẢN SLONIK CHỈ ĐƯỢC THỰC HIỆN TRÊN SỐ GỐC, NGOẠI TRỪ “start_OriginNode.sh” VÀ “start_SubscriberNode.sh” NÊN ĐƯỢC THỰC HIỆN RIÊNG TƯ.

-bash-4.1$ slonik initalize.slonik
-bash-4.1$ slonik create_set.slonik
create_set.slonik:13: Set 1 ...created
create_set.slonik:16: PKey table *** public.foo *** added.
-bash-4.1$ sh start_OriginNode.sh
-bash-4.1$ sh start_SubscriberNode.sh //ON SUBSCRIBER NODE
-bash-4.1$ slonik subscribe_set.slonik

Sau khi thực hiện thành công tập lệnh trên, bạn có thể nhận thấy dữ liệu trên Nguồn gốc (masterdb) đã được sao chép sang Người đăng ký (slave). Đồng thời không cho phép bất kỳ hoạt động DML nào trên nút Người đăng ký:

slavedb=# select * from foo;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
(3 rows)

slavedb=# insert into foo values (4,'PG-Experts','Image2');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0

Tuyệt vời… Chúng tôi đã chuyển dữ liệu sang phiên bản PostgreSQL 9.3.5 mới hơn. Ở giai đoạn này, nếu bạn cảm thấy tất cả dữ liệu đã được sao chép sang Nút người đăng ký, thì bạn có thể thực hiện chuyển đổi.

3. Đang thử nghiệm Chuyển mạch / Chuyển lại.

Hãy chuyển sang phiên bản mới nhất bằng tập lệnh và thử chèn dữ liệu trên các nút Người đăng ký / Nguồn gốc.

-bash-4.1$ slonik switchover.slonik
switchover.slonik:8: Set 1 has been moved from Node 1 to Node 2

slavedb=# insert into foo values (4,'PG-Experts','Image2');
INSERT 0 1

masterdb=# select * from foo ;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
4 | PG-Experts | Image2
(4 rows)

masterdb=# insert into foo values (5,'PG-Experts','Image3');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0

Hoàn hảo… Đây là những gì chúng ta đang tìm kiếm, hiện tại, slaveb (Nút thuê bao) đang chạy phiên bản PG 9.3.5 chấp nhận dữ liệu và masterdb (Nút nguồn) nhận dữ liệu slave. Nó cũng từ chối các DML được thực thi trên masterdb.

Nhật ký Slony-I hiển thị các chuyển động id nút gốc / người đăng ký tại thời điểm Chuyển mạch:

2014-12-12 04:55:06 PST CONFIG moveSet: set_id=1 old_origin=1 new_origin=2
2014-12-12 04:55:06 PST CONFIG storeListen: li_origin=1 li_receiver=2 li_provider=1
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: update provider configuration
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: helper thread for provider 1 terminated
2014-12-12 04:55:06 PST CONFIG remoteWorkerThread_1: disconnecting from data provider 1
...
...
2014-12-12 04:55:11 PST INFO start processing ACCEPT_SET
2014-12-12 04:55:11 PST INFO ACCEPT: set=1
2014-12-12 04:55:11 PST INFO ACCEPT: old origin=1
2014-12-12 04:55:11 PST INFO ACCEPT: new origin=2
2014-12-12 04:55:11 PST INFO ACCEPT: move set seq=5000006393
2014-12-12 04:55:11 PST INFO got parms ACCEPT_SET

Nếu bạn gặp bất kỳ sự cố nào ở giai đoạn này, bạn có thể chuyển về phiên bản cũ hơn. Sau khi chuyển đổi lại, bạn có thể tiếp tục với phiên bản Cũ hơn cho đến khi ứng dụng của bạn hoặc các sự cố khác được khắc phục. Đây là kế hoạch khôi phục hoàn hảo mà không mất nhiều thời gian trong trường hợp có sự cố sau khi chuyển đổi ..

-bash-4.1$ slonik switchback.slonik
switchback.slonik:8: Set 1 has been moved from Node 2 to Node 1

slavedb=# insert into foo values (5,'PG-Experts','Image3');
ERROR: Slony-I: Table foo is replicated and cannot be modified on a subscriber node - role=0

masterdb=# insert into foo values (5,'PG-Experts','Image3');
INSERT 0 1

slavedb=# select * from foo ;
id | name | image
----+----------------------+-------
1 | Raghav | test1
2 | Rao | test2
3 | Rags | test3
4 | PG-Experts | Image2
5 | PG-Experts | Image3
(5 rows)

Rất đẹp…!!! Đây không phải là phương thức khôi phục chính xác với thời gian ngừng hoạt động tối thiểu? Có, đây là một sự chuyển đổi hoàn hảo giữa các nút mà không bỏ lỡ giao dịch.

Nhật ký hiển thị quá trình chuyển đổi từ Người đăng ký sang Nút gốc:

2014-12-12 04:58:45 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1
2014-12-12 04:58:45 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: update provider configuration
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: helper thread for provider 2 terminated
2014-12-12 04:58:45 PST CONFIG remoteWorkerThread_2: disconnecting from data provider 2
2014-12-12 04:58:46 PST CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
...
...
2014-12-12 04:58:47 PST INFO start processing ACCEPT_SET
2014-12-12 04:58:47 PST INFO ACCEPT: set=1
2014-12-12 04:58:47 PST INFO ACCEPT: old origin=2
2014-12-12 04:58:47 PST INFO ACCEPT: new origin=1
2014-12-12 04:58:47 PST INFO ACCEPT: move set seq=5000006403
2014-12-12 04:58:47 PST INFO got parms ACCEPT_SET
2014-12-12 04:58:48 PST CONFIG moveSet: set_id=1 old_origin=2 new_origin=1

Tại thời điểm này, bạn có thể nhận thấy, không có giao dịch nào bị mất trong quá trình chuyển đổi giữa các phiên bản PostgreSQL. Chỉ có thời gian chết ứng dụng của bạn mới có thể bắt đầu / dừng để kết nối với các nút Nguồn gốc và Người đăng ký, nhưng trong khi các nút Nguồn gốc / Người đăng ký không bao giờ bị gỡ xuống, chúng chỉ hoạt động.

Hãy nhớ rằng, phương pháp hiển thị ở đây không chỉ hữu ích cho việc nâng cấp mà còn là phương pháp tương tự trong Slony-I để di chuyển giữa các nút.

Cảm ơn vì sự kiên nhẫn của bạn :). Hy vọng bài đăng này sẽ giúp bạn nâng cấp PostgreSQL với thời gian chết tối thiểu bằng cách sử dụng Slony-I bao gồm cả kế hoạch khôi phục thích hợp.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Truy vấn SQL để tìm bản ghi có ID không có trong bảng khác

  2. PostgreSQL:Truy vấn song song trong hành động

  3. Chuyển đổi vai trò sau khi kết nối với cơ sở dữ liệu

  4. chú thích ngủ đông thích hợp cho byte []

  5. Báo cáo xu hướng PostgreSQL 2019:Đám mây riêng và đám mây công cộng, Di chuyển, Kết hợp cơ sở dữ liệu &Lý do hàng đầu được sử dụng