Nâng cấp cơ sở dữ liệu của bạn lên phiên bản PostgreSQL 10 - Những điều bạn nên biết

Khi ngày càng có nhiều bài đăng về PostgreSQL 11 xuất hiện trên web, bạn càng cảm thấy lỗi thời hơn khi sử dụng Postgres 9. Mặc dù việc phát hành phiên bản PostgreSQL 10 chỉ mới diễn ra cách đây vài tháng, nhưng mọi người đã nói về phiên bản tiếp theo. Mọi thứ đang chuyển động, vì vậy bạn không muốn bị bỏ lại phía sau. Trong blog này, chúng tôi sẽ thảo luận những điều bạn cần biết để nâng cấp lên phiên bản mới nhất, Postgres 10.

Tùy chọn nâng cấp

Điều đầu tiên bạn nên biết trước khi bắt đầu là có một số cách để thực hiện nâng cấp:

1. pg_dumpall truyền thống (pg_dump) / pg_restore (psql)
2. pg_upgrade truyền thống
3. Sao chép dựa trên trình kích hoạt (Slony, tự viết)
4. Sử dụng sao chép pglogical

Tại sao lại có sự đa dạng như vậy? Bởi vì mỗi nơi có một lịch sử khác nhau, đòi hỏi những nỗ lực khác nhau để thiết lập và cung cấp các dịch vụ khác nhau. Hãy xem xét kỹ hơn từng người trong số họ.

Kết xuất / Khôi phục truyền thống

pg_dump t > /tmp/f
psql -p 5433 -f /tmp/f

Kết xuất / khôi phục truyền thống mất nhiều thời gian nhất để hoàn thành và nó thường là lựa chọn phổ biến cho những người có đủ khả năng chi trả thời gian chết. Đầu tiên, nó dễ dàng như tạo một bản sao lưu hợp lý và khôi phục nó vào phiên bản mới, cao hơn của cơ sở dữ liệu. Bạn có thể nói rằng đó không phải là một bản nâng cấp, thực sự, khi bạn "nhập" dữ liệu của mình vào một "cấu trúc mới". Kết quả là bạn sẽ có hai thiết lập - một cũ (phiên bản thấp hơn) và một mới được nâng cấp. Nếu quá trình khôi phục kết thúc mà không có lỗi, bạn đang ở đó khá nhiều. Nếu không, bạn phải sửa đổi cụm cũ hiện có để loại bỏ bất kỳ lỗi nào và bắt đầu lại quy trình.

Nếu bạn sử dụng psql để nhập, bạn cũng có thể cần tự tạo một số tập lệnh tải trước để thực thi trên thiết lập mới trước khi di chuyển. Ví dụ:bạn muốn pg_dumpall -g để nhận danh sách các vai trò cần thiết để chuẩn bị trong thiết lập mới hoặc chạy pg_dump -x ngược lại để bỏ qua các quyền từ vai trò cũ. Quá trình này khá đơn giản trên các cơ sở dữ liệu nhỏ, độ phức tạp tăng dần theo kích thước và độ phức tạp của cấu trúc db của bạn và phụ thuộc vào những tính năng bạn đã thiết lập. Về cơ bản để phương pháp này thành công, bạn cần tiếp tục thử và sửa cho đến khi nâng cấp thành công.

Những lợi thế khi sử dụng phương pháp này bao gồm ...

• Mặc dù bạn có thể mất nhiều thời gian với một bản sao lưu mà bạn đã thực hiện - tải trên máy chủ cũ chỉ bằng một bản sao lưu.
• Phương pháp này chủ yếu chỉ là một trình tự sao lưu-khôi phục (có thể có một số câu thần chú, bài hát và tiếng trống)
• Sử dụng phương pháp này là cách nâng cấp lâu đời nhất và đã được NHIỀU người xác minh

Cuối cùng khi hoàn tất nâng cấp, bạn phải tắt máy chủ cũ hoặc chấp nhận một số mất dữ liệu (hoặc cách khác là phát lại DML đã xảy ra trên máy chủ cũ trong khi khôi phục bản sao lưu vào máy chủ mới). Và thời gian dành cho việc đó có liên quan đến kích thước cơ sở dữ liệu của bạn.

Tất nhiên, bạn có thể bắt đầu "sử dụng" một cơ sở dữ liệu mới trước khi quá trình khôi phục hoàn tất (đặc biệt là trước khi tất cả các chỉ mục được xây dựng - thường mất nhiều thời gian nhất dành cho các chỉ mục). Nhưng tuy nhiên, thời gian chết như vậy thường không thể chấp nhận được.

pg_upgrade truyền thống

MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/initdb -D tl0 >/tmp/suppressing_to_save_screen_space_read_it

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
MacBook-Air:~ vao$ /usr/local/Cellar/postgresql/10.2/bin/pg_upgrade -b /usr/local/Cellar/postgresql/9.5.3/bin -B /usr/local/Cellar/postgresql/10.2/bin -d t -D tl0 | tail
Creating script to delete old cluster                        ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster’s data files:
    ./delete_old_cluster.sh

Pg_upgrade truyền thống được tạo ra để rút ngắn thời gian nâng cấp lên phiên bản chính. Tùy thuộc vào số lượng quan hệ bạn có, nó có thể nhanh đến vài phút (giây trong trường hợp vô lý, như cơ sở dữ liệu một bảng và hàng giờ trong "trường hợp ngược lại") đặc biệt là với đối số --link.

Trình tự chuẩn bị hơi khác so với phương pháp nâng cấp đầu tiên. Để mô phỏng nâng cấp và do đó để kiểm tra xem có khả thi hay không, bạn nên tạo bản sao phát trực tuyến hoặc khôi phục máy chủ dự phòng từ WALs. Tại sao điều này lại phức tạp như vậy? Bạn muốn đảm bảo kiểm tra nâng cấp trên cơ sở dữ liệu đóng-trong-trạng thái như ban đầu. Sao chép "nhị phân" hoặc PITR sẽ giúp chúng ta ở đây. Sau khi hoàn tất quá trình khôi phục và recovery_target_action =promotion (PITR) hoặc thăng cấp nô lệ mới được xây dựng (quảng bá pg_ctl hoặc đặt tệp kích hoạt) (nhân rộng trực tuyến), bạn có thể thử chạy pg_upgrade. Kiểm tra pg_upgrade_internal.log sẽ cho bạn biết quá trình có thành công hay không. Hơn nữa, bạn có cách tiếp cận thử và sửa giống như phương pháp trước đó. Bạn lưu các hành động được thực hiện đối với cơ sở dữ liệu thử nghiệm trong một tập lệnh, cho đến khi bạn pg_upgrade nó thành công. Ngoài ra, bạn có thể hủy kiểm tra không cần thiết nữa nâng cấp cơ sở dữ liệu, chạy tập lệnh đã lưu để chuẩn bị cơ sở dữ liệu gốc để thực hiện nâng cấp.

Những lợi thế khi sử dụng phương pháp này bao gồm…

• Thời gian chết ngắn hơn so với sao lưu / khôi phục hợp lý
• Một quy trình gọn gàng - pg_upgrade nâng cấp cơ sở dữ liệu ban đầu với dữ liệu và cấu trúc hiện có
• Đã được sử dụng rất nhiều trong quá khứ và vẫn sẽ là ưu tiên cho hầu hết các DBA chạy phiên bản dưới 9.4 (cho phép sử dụng pglogical)

Những bất lợi của việc sử dụng phương pháp này bao gồm…

• Yêu cầu thời gian chết

Sao chép dựa trên trình kích hoạt

Giả sử phiên bản 10 có trên cổng 5433 và có cùng một bảng được chuẩn bị:

db=# create server upgrade_to_10 foreign data wrapper postgres_fdw options (port '5433', dbname 'dbl0');
CREATE SERVER
Time: 9.135 ms
db=# create user mapping for vao SERVER upgrade_to_10 options (user 'vao');
CREATE USER MAPPING
Time: 8.741 ms
db=# create foreign table rl0 (pk int, t text) server upgrade_to_10 options (table_name 'r');
CREATE FOREIGN TABLE
Time: 9.358 ms

Đây là một fn () cực kỳ đơn giản và kích hoạt để sao chép logic rất cơ bản. Cách tiếp cận như vậy quá sơ khai, nó sẽ không hoạt động với các khóa ngoại, nhưng mã ngắn:

db=# create or replace function tf() returns trigger as $$
begin
 if TG_0P = 'INSERT' then
   insert into r10 select NEW.*;
 elseif TG_0P = 'UPDATE' then
   delete from rl0 where pk = NEW.pk;
   insert into rl0 select NEW.*;
 elseif TG_0P = 'DELETE' then
   delete from rl0 where pk = OLD.pk;
 end if;
return case when TG_0P in ('INSERT','UPDATE') then NEW else OLD end;
end;
SS language plpgsql;
CREATE FUNCTION
Time: 8.531 ms
db=# create trigger t before insert or update or delete on r for each row execute procedure tf(); CREATE TRIGGER
Time: 8.813 ms

Ví dụ:

db=# insert into r(t) select chr(g) from generate_series(70,75) g;
INSERT 0 6
Time: 12.621 ms
db=# update r set t = 'updated' where pk=2;
UPDATE 1
Time: 10.398 ms
db=# delete from r where pk=1;
DELETE 1
Time: 9.634 ms
db=# select * from r;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 9.026 ms
db=# select * from rl0;
 pk |    t
----+---------
  3 | H
  4 | I
  5 | J
  6 | K
  2 | updated
(5 rows)

Time: 1.201 ms

Cuối cùng, hãy kiểm tra xem chúng tôi có sao chép sang một cơ sở dữ liệu khác không:

db=# select *,current_setting('port') from dblink('upgrade.to.lO','select setting from pg_settings where name=$$port$$') as t(setting_10 text);
 setting_10 | currerrt.setting
------------+------------------
 5433       | 5432
(l row)

Time: 23.633 ms

Tôi sẽ gọi phương pháp này là kỳ lạ nhất. Cả hai thực tế là với sao chép trực tuyến và sau đó với pglogical, việc sử dụng sao chép dựa trên trình kích hoạt trở nên ít phổ biến hơn. Nó có tải cao hơn trên bản chính, tăng độ phức tạp trong quá trình thiết lập và thiếu tài liệu có cấu trúc tốt. Không có sự chuẩn bị (chẳng hạn như) cho quy trình ở đây, vì bạn chỉ muốn thiết lập Slony trên các phiên bản chính khác nhau.

Những lợi thế của việc sử dụng phương pháp này bao gồm…

• Không cần sao lưu và không cần thời gian chết (đặc biệt là bạn đang sử dụng một số pgbouncer hoặc haproxy).

Những bất lợi của việc sử dụng phương pháp này bao gồm…

• Độ phức tạp cao của thiết lập
• Thiếu tài liệu có cấu trúc
• Không phổ biến lắm - ít trường hợp người dùng hơn để nghiên cứu (và chia sẻ)

Cùng một dòng, sao chép kích hoạt tự viết là một cách khả thi khác để nâng cấp. Mặc dù ý tưởng giống nhau (bạn tạo cơ sở dữ liệu phiên bản cao hơn mới và thiết lập trình kích hoạt trên phiên bản thấp hơn để gửi dữ liệu đã sửa đổi đến nó), bạn sẽ rõ ràng về việc tự thiết lập bằng văn bản. Bạn sẽ không cần bất kỳ sự hỗ trợ nào và do đó có thể sử dụng ít tài nguyên hơn khi chạy nó. Tất nhiên, vì lý do tương tự, bạn có thể sẽ kết thúc với một số tính năng bị thiếu hoặc không hoạt động như mong đợi. Nếu bạn có một số bảng để chuyển sang phiên bản mới, một tùy chọn như vậy có thể sẽ khiến bạn mất ít thời gian hơn và nếu được thực hiện tốt, có thể ít tốn tài nguyên hơn. Như một phần thưởng, bạn có thể kết hợp một số chuyển đổi ETL với nâng cấp, chuyển sang phiên bản mới mà không cần thời gian chết.

Sao chép lôgic với pglogical

Đây là một cách nâng cấp Postgres mới rất hứa hẹn. Ý tưởng là thiết lập sao chép hợp lý giữa các phiên bản chính khác nhau và theo nghĩa đen có một cơ sở dữ liệu phiên bản song song, cao hơn (hoặc thấp hơn) chạy cùng một dữ liệu. Khi bạn đã sẵn sàng, bạn chỉ cần chuyển kết nối với ứng dụng của mình từ cũ sang mới.

Những lợi thế của việc sử dụng phương pháp này bao gồm…

• Về cơ bản không có thời gian chết
• Tính năng cực kỳ hứa hẹn, ít tốn công sức hơn nhiều so với sao chép dựa trên trình kích hoạt

Những bất lợi của việc sử dụng phương pháp này bao gồm…

• Vẫn rất phức tạp để thiết lập (đặc biệt là đối với các phiên bản cũ hơn)
• Thiếu tài liệu có cấu trúc
• Không phổ biến lắm - ít trường hợp người dùng hơn để nghiên cứu (và chia sẻ)

Cả quá trình di chuyển phiên bản chính dựa trên trình kích hoạt và sao chép pglogical đều có thể được sử dụng để hạ cấp phiên bản (tất nhiên là lên đến một số giá trị hợp lý, ví dụ:pglogical chỉ có sẵn từ phiên bản 9.4 và kích hoạt sao chép ngày càng khó thiết lập như phiên bản bạn muốn hạ cấp để già đi).

Các hành động cần thực hiện trước khi nâng cấp

• Sao lưu
• Đảm bảo có đủ dung lượng ổ đĩa
• Kiểm tra các tiện ích mở rộng của bạn (điều quan trọng là mọi mô-đun bên ngoài cũng tương thích nhị phân, mặc dù pg_upgrade không thể kiểm tra điều này)
• Đảm bảo sử dụng cùng một datcollate và datctype, v.v. (kiểm tra pg_database) trên cơ sở dữ liệu mới
• Kiểm tra (DDL + Drop) các chế độ xem, chức năng, tiện ích mở rộng, các loại có thể phá vỡ nâng cấp
• Sử dụng --check trước khi thực sự pg_upgrade

Các hành động sẽ được thực hiện sau khi nâng cấp

• Tham khảo ý kiến ​​pg_upgrade_server.log (nếu bạn đã sử dụng pg_upgrade)
• Chạy phân tích trên cơ sở dữ liệu được nâng cấp (tùy chọn, vì nó sẽ được thực hiện bởi autovacuum, nhưng bạn có thể chọn những mối quan hệ nào sẽ được phân tích trước nếu bạn tự làm)
• Làm nóng trước các trang phổ biến (tùy chọn, nhưng có thể tăng hiệu suất ngay từ đầu)

Kết luận

Dưới đây là một số lưu ý chung cần biết trước khi bạn quyết định chuyển sang PostgreSQL phiên bản 10…

• pg_sequences đã được giới thiệu, thay đổi hoạt động của SELECT * FROM sequence_name phổ biến trước đây - hiện chỉ có last_value | log_cnt | is_called được trả về, ẩn với bạn "thuộc tính ban đầu" (điều chỉnh bất kỳ mã nào dựa trên hành vi đã thay đổi)
• pg_basebackup luồng WAL theo mặc định. Sau khi nâng cấp, bạn có thể cần sửa đổi các tập lệnh của mình (tùy chọn -x đã bị xóa)
• Tất cả các hành động pg_ctl đang chờ hoàn thành. Trước đây, bạn phải thêm -w để tránh cố gắng kết nối với cơ sở dữ liệu ngay sau khi bắt đầu pg_ctl. Vì vậy, nếu bạn vẫn muốn sử dụng start hoặc stop "async", bạn phải đánh dấu rõ ràng nó bằng -W. Bạn có thể cần phải điều chỉnh các tập lệnh của mình để chúng hoạt động như dự kiến.
• Tất cả các tập lệnh để lưu trữ WAL hoặc giám sát / kiểm soát sao chép luồng hoặc PITR cần được xem xét, để điều chỉnh chúng thành tên xlog đã thay đổi. Ví dụ. select * from pg_is_xlog_replay_paused () sẽ không hiển thị cho bạn trạng thái phát lại WALs nô lệ nữa - thay vào đó bạn phải sử dụng select * from pg_is_wal_replay_paused (). Ngoài ra cp / blah / pg_xlog / * cần được thay đổi thành / blah / pg_wal / * và về cơ bản như vậy đối với tất cả các lần xuất hiện của pg_xlog. Lý do đằng sau sự thay đổi lớn, không tương thích ngược như vậy là để giải quyết trường hợp người mới xóa nhật ký ghi trước để "dọn dẹp một số không gian" bằng cách xóa nhật ký và mất cơ sở dữ liệu.
• Điều chỉnh các tập lệnh bằng pg_stat_replication cho các tên mới (vị trí đã thay đổi thành lsn)
• Điều chỉnh các truy vấn bằng cách đặt các hàm trả về nếu cần
• Nếu bạn đã sử dụng pglogical làm tiện ích mở rộng trước phiên bản 10, bạn có thể cần điều chỉnh giá trị thay đổi pg_hba.conf giữa các "cột"
• Điều chỉnh tập lệnh cho tên mới của pg_log là nhật ký, vì vậy, một cái gì đó như find / pg_data / pg_log / postgresql- * -mmin + $ ((60 * 48)) -type f -exec bash /blah/moveto.s3 .sh {} \; sẽ hoạt động. Tất nhiên, bạn có thể tạo một liên kết tượng trưng để thay thế, nhưng cần phải thực hiện hành động để tìm nhật ký ở vị trí mặc định. Một thay đổi nhỏ khác đối với giá trị mặc định là log_line_prefix - nếu biểu thức chính quy của bạn phụ thuộc vào một định dạng nhất định, bạn cần phải điều chỉnh nó.
• Nếu bạn vẫn đang sử dụng mật khẩu chưa được mã hóa trong cơ sở dữ liệu Postgres của mình, bản phát hành hoàn chỉnh này sẽ xóa mật khẩu đó. Vì vậy, đã đến lúc sắp xếp mọi thứ cho những người dựa vào --mã hóa ...
• Phần còn lại của các thay đổi không tương thích với các bản phát hành trước đó là quá mới để có thể tham chiếu trong nhiều mã (min_parallel_relation_size) hoặc quá cổ (tsearch2 bên ngoài) hoặc quá kỳ lạ (loại bỏ hỗ trợ dấu thời gian dấu phẩy động trong bản dựng), vì vậy chúng tôi sẽ bỏ qua chúng. Tất nhiên, chúng được liệt kê trên trang phát hành.
• Giống như với 9.5 đến 9.6, bạn có thể cần điều chỉnh các tập lệnh của mình để truy vấn pg_stat_activity (một cột mới và các giá trị mới có thể có)
• Nếu bạn đang lưu / phân tích đầu ra chi tiết chân không, bạn có thể cần điều chỉnh mã của mình
• Ngoài ra, bạn có thể muốn xem cách triển khai phân vùng mới - bạn có thể muốn cấu trúc lại "bộ" hiện có của mình để tuân thủ các "tiêu chuẩn" mới
• kiểm tra dòng thời gian (sẽ được đặt lại cho cơ sở dữ liệu mới nếu bạn pg_upgrade)

Ngoài các bước mà bạn phải biết để nâng cấp lên 10, có rất nhiều điều khiến bản phát hành này trở thành một bản rất được mong đợi. Vui lòng đọc phần về những thay đổi trong ghi chú phát hành hoặc blog depesz.