Sử dụng bản sao lôgic PostgreSQL để duy trì máy chủ kiểm tra đọc / ghi luôn cập nhật

Trong mục blog này, chúng ta sẽ nói về bản sao lôgic trong PostgreSQL:các trường hợp sử dụng của nó, thông tin chung về trạng thái của công nghệ này và trường hợp sử dụng đặc biệt nói riêng về cách thiết lập nút đăng ký (bản sao) của máy chủ chính theo thứ tự hoạt động như một máy chủ cơ sở dữ liệu cho môi trường thử nghiệm và những thách thức đã gặp phải.

Giới thiệu

Sao chép lôgic, được giới thiệu chính thức trong PostgreSQL 10, là công nghệ sao chép mới nhất được cung cấp bởi cộng đồng PostgreSQL. Sao chép lôgic là sự tiếp nối di sản của sao chép vật lý mà nó chia sẻ rất nhiều ý tưởng và mã. Bản sao lôgic hoạt động giống như bản sao vật lý bằng cách sử dụng WAL để ghi lại các thay đổi lôgic độc lập với phiên bản hoặc kiến trúc cụ thể. Để có thể cung cấp bản sao hợp lý cho sản phẩm cốt lõi, cộng đồng PostgreSQL đã phải trải qua một chặng đường dài.

Các loại sao chép và Lịch sử sao chép PostgreSQL

Các kiểu sao chép trong cơ sở dữ liệu có thể được phân loại như sau:

Sao chép vật lý (nhị phân AKA)
- Mức hệ điều hành (sao chép vSphere)
- Cấp độ hệ thống tệp (DRBD)
- Cấp độ cơ sở dữ liệu (dựa trên WAL)
Sao chép lôgic (Mức cơ sở dữ liệu)
- Dựa trên trình kích hoạt (DBMirror, Slony)
- Phần mềm trung gian (pgpool)
- Dựa trên WAL (sao chép lôgic, logic)

Lộ trình mang đến sự tái tạo hợp lý dựa trên WAL ngày nay là:

2001:DBMirror (dựa trên trình kích hoạt)
2004:Slony1 (dựa trên trình kích hoạt), pgpool (phần mềm trung gian)
2005:PITR (dựa trên WAL) được giới thiệu trong PostgreSQL 8.0
2006:Chế độ chờ ấm áp trong PostgreSQL 8.2
2010:Nhân rộng luồng vật lý, chế độ chờ nóng trong PostgreSQL 9.0
2011:Sao chép luồng đồng bộ trong PostgreSQL 9.1
2012:Sao chép luồng theo tầng trong PostgreSQL 9.2
2013:Công nhân nền tảng trong PostgreSQL 9.3
2014:API giải mã logic, các khe sao chép. (Nền tảng cho sự sao chép lôgic) trong PostgreSQL 9.4
2015:2ndQuadrant giới thiệu pglogical, tổ tiên hoặc Logical Replication
2017:Tái tạo logic trong cốt lõi PostgreSQL 10!

Như chúng ta có thể thấy rất nhiều công nghệ được hợp tác để biến Logical Replication trở thành hiện thực:lưu trữ WAL, các standbys ấm / nóng, sao chép WAL vật lý, background worker, giải mã logic. Giả sử người đọc đã quen thuộc với hầu hết các khái niệm về sao chép vật lý, chúng ta sẽ nói về các thành phần cơ bản của Sao chép lôgic.

Các khái niệm cơ bản về PostgreSQL Logical Replication

Một số thuật ngữ:

Xuất bản: Một tập hợp các thay đổi từ một tập hợp các bảng được xác định trong cơ sở dữ liệu cụ thể trên máy chủ chính nhân bản vật lý. Một Ấn phẩm có thể xử lý tất cả hoặc một số:CHÈN, XÓA, CẬP NHẬT, TRUNCATE.
Nút nhà xuất bản: Máy chủ lưu trữ ấn phẩm.
Nhận dạng bản sao: Một cách để xác định hàng ở phía người đăng ký cho các CẬP NHẬT và XÓA.
Đăng ký: Một kết nối với nút nhà xuất bản và một hoặc nhiều ấn phẩm trong đó. Một đăng ký sử dụng một vị trí sao chép chuyên dụng trên nhà xuất bản để nhân rộng. Các khe sao chép bổ sung có thể được sử dụng cho bước đồng bộ hóa ban đầu.
Nút người đăng ký: Máy chủ nơi đăng ký cư trú.

Tái tạo logic tuân theo mô hình xuất bản / đăng ký. Một hoặc nhiều người đăng ký có thể đăng ký một hoặc nhiều ấn phẩm trên một nút nhà xuất bản. Người đăng ký có thể tái xuất bản để cho phép sao chép theo tầng. Bản sao lôgic của một bảng bao gồm hai giai đoạn:

Chụp nhanh bảng trên nhà xuất bản và sao chép nó cho người đăng ký
Áp dụng tất cả các thay đổi (kể từ ảnh chụp nhanh) theo cùng một trình tự

Bản sao lôgic mang tính chất giao dịch và đảm bảo rằng thứ tự các thay đổi được áp dụng cho người đăng ký vẫn giống với nhà xuất bản. Sao chép logic mang lại nhiều tự do hơn so với sao chép vật lý (nhị phân), do đó có thể được sử dụng theo nhiều cách hơn:

Cơ sở dữ liệu đơn lẻ hoặc sao chép bảng cụ thể (không cần sao chép toàn bộ cụm)
Đặt trình kích hoạt cho người đăng ký cho một nhiệm vụ cụ thể (chẳng hạn như ẩn danh, một chủ đề khá nóng sau khi GDPR có hiệu lực)
Có một nút người đăng ký thu thập dữ liệu từ nhiều nút của nhà xuất bản, do đó cho phép xử lý phân tích tập trung
Sao chép giữa các phiên bản / kiến trúc / nền tảng khác nhau (nâng cấp không mất thời gian chết)
Sử dụng nút thuê bao làm máy chủ cơ sở dữ liệu cho môi trường thử nghiệm / phát triển. Tại sao chúng tôi muốn điều này là vì thử nghiệm dựa trên dữ liệu thực là loại thử nghiệm thực tế nhất.

Cảnh báo và Hạn chế

Có một số điều chúng ta phải lưu ý khi sử dụng bản sao hợp lý, một số trong số chúng có thể ảnh hưởng đến một số quyết định thiết kế nhưng những điều khác có thể dẫn đến các sự cố nghiêm trọng.

Hạn chế

Chỉ các hoạt động DML được hỗ trợ. Không có DDL. Lược đồ phải được xác định trước
Các chuỗi không được sao chép
Các đối tượng lớn không được sao chép
Chỉ hỗ trợ các bảng cơ sở thuần túy (chế độ xem vật thể hóa, bảng gốc phân vùng, bảng ngoại không được hỗ trợ)

Lưu ý

Vấn đề cơ bản mà sớm hay muộn chúng ta sẽ phải đối mặt khi sử dụng tính năng Logical Replication là xung đột trên người đăng ký. Người đăng ký là một máy chủ đọc / ghi bình thường có thể hoạt động như một máy chủ chính trong thiết lập sao chép vật lý hoặc thậm chí là nhà xuất bản trong một thiết lập sao chép lôgic theo tầng. Miễn là việc ghi trên các bảng đã đăng ký được thực hiện, có thể có xung đột . Xung đột phát sinh khi dữ liệu được sao chép vi phạm một ràng buộc trên bảng mà chúng được áp dụng. Thông thường, thao tác gây ra điều này là CHÈN, XÓA hoặc CẬP NHẬT không có bất kỳ tác dụng nào do thiếu hàng sẽ không gây ra xung đột. Khi xung đột phát sinh, việc nhân rộng sẽ dừng lại. Trình làm việc nền logic sẽ được khởi động lại trong khoảng thời gian được chỉ định (wal_retrieve_retry_interval), tuy nhiên, quá trình sao chép sẽ thất bại một lần nữa cho đến khi nguyên nhân của xung đột được giải quyết. Đây là tình trạng nguy cấp cần phải xử lý ngay. Không làm như vậy sẽ làm cho vị trí sao chép bị kẹt ở vị trí hiện tại, nút nhà xuất bản sẽ bắt đầu tích lũy WAL và chắc chắn nút nhà xuất bản sẽ hết dung lượng đĩa . Xung đột là lý do phổ biến nhất khiến quá trình sao chép có thể dừng lại nhưng bất kỳ điều kiện sai sót nào khác cũng sẽ gây ra hậu quả tương tự:ví dụ:chúng tôi đã thêm một cột NOT NULL mới trên bảng đã đăng ký nhưng quên xác định giá trị mặc định hoặc thêm một cột trên bảng đã xuất bản nhưng quên xác định nó trên bảng đã đăng ký hoặc mắc lỗi về loại của nó và hai loại không tương thích. Tất cả những lỗi đó sẽ ngừng sao chép. Có hai cách để giải quyết xung đột:

Giải quyết vấn đề thực tế
Bỏ qua giao dịch không thành công bằng cách gọi pg_replication_origin_advance

Giải pháp b. như được hiển thị ở đây có thể nguy hiểm và phức tạp vì về cơ bản đây là một quá trình thử và sai và nếu một người chọn LSN hiện tại trên nhà xuất bản, họ có thể dễ dàng kết thúc với hệ thống sao chép bị hỏng vì có thể có các hoạt động giữa LSN có vấn đề và LSN hiện tại mà chúng tôi muốn giữ lại. Vì vậy, cách tốt nhất là thực sự giải quyết vấn đề ở phía thuê bao. Ví dụ. nếu vi phạm KEY DUY NHẤT phát sinh thì chúng tôi có thể cập nhật dữ liệu về người đăng ký hoặc chỉ cần xóa hàng. Trong môi trường sản xuất, tất cả điều này phải được tự động hóa hoặc ít nhất là bán tự động.

Thiết lập các nút nhà xuất bản và người đăng ký

Để có cái nhìn tổng quan chung về quá trình sao chép hợp lý trong thực tế, vui lòng đọc blog này.

Các tham số liên quan để sao chép lôgic là:

Phía nhà xuất bản
- wal_level> =“logic”
- max_replication_slots> =#subscriptions + đồng bộ hóa bảng ban đầu
- max_wal_senders> =max_replication_slots + other_physical_standbys
Phía người đăng ký
- max_replication_slots> =#subscriptions
- max_logical_replication_workers> =#subscriptions + đồng bộ hóa bảng ban đầu
- max_worker_processes> =max_logical_replication_workers + 1 + max_parallel_workers

Chúng tôi sẽ tập trung vào những cân nhắc đặc biệt phát sinh từ mục đích đặc biệt của chúng tôi mà chúng tôi cần sao chép hợp lý để đạt được: tạo một cụm cơ sở dữ liệu thử nghiệm để tổ chức thử nghiệm sử dụng . Ấn phẩm có thể được xác định cho tất cả các bảng hoặc từng bảng. Tôi đề xuất phương pháp tiếp cận từng bàn vì nó mang lại cho chúng ta sự linh hoạt tối đa. Các bước chung có thể được tóm tắt như sau:

Thực hiện một initdb mới trên nút người đăng ký
Kết xuất giản đồ của cụm nhà xuất bản và sao chép vào nút người đăng ký
Tạo giản đồ về người đăng ký
Quyết định bảng nào bạn cần và bảng nào bạn không cần.

Liên quan đến gạch đầu dòng ở trên, có hai lý do tại sao bạn có thể không cần một bảng được sao chép hoặc thiết lập để sao chép:

Đây là một bảng giả không có tầm quan trọng (và có thể bạn cũng nên loại bỏ nó khỏi phiên bản sản xuất)
là một bảng cục bộ đối với môi trường sản xuất, có nghĩa là hoàn toàn hợp lý khi cùng một bảng trong môi trường thử nghiệm (người đăng ký) có dữ liệu riêng

Tất cả các bảng tham gia vào quá trình sao chép lôgic phải có NHẬN DẠNG PHIẾU. Theo mặc định, đây là KHÓA CHÍNH, và nếu không có, một khóa DUY NHẤT có thể được xác định. Bước tiếp theo để tìm trạng thái của các bảng liên quan đến IDENTITY REPLICA.

Tìm các bảng không có ứng cử viên rõ ràng nào cho REPLICA IDENTITY

select table_schema||'.'||table_name from information_schema.tables where table_type='BASE TABLE' AND table_schema||'.'||table_name NOT IN (select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type in ('PRIMARY KEY','UNIQUE')) AND table_schema NOT IN ('information_schema','pg_catalog') ;

Tìm các bảng không có KHÓA CHÍNH nhưng có CHỈ SỐ DUY NHẤT

select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type = 'UNIQUE' EXCEPT select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type = 'PRIMARY KEY';

Xem qua các danh sách ở trên và quyết định xem phải làm gì với mỗi bảng

Tạo ấn phẩm với các bảng mà có PK

select 'CREATE PUBLICATION data_for_testdb_pub FOR TABLE ONLY ' || string_agg(qry.tblname,', ONLY ') FROM (select table_schema||'.'||quote_ident(table_name) as tblname from information_schema.tables where table_type='BASE TABLE' AND table_schema||'.'||table_name IN (select table_schema||'.'||table_name from information_schema.table_constraints WHERE constraint_type in ('PRIMARY KEY')) AND table_schema NOT IN( 'information_schema','pg_catalog')  ORDER BY 1) as qry;
\gexec

Sau đó, tạo đăng ký trên nút người đăng ký

create subscription data_for_testdb_pub CONNECTION 'dbname=yourdb host=yourdbhost user=repmgr' PUBLICATION data_for_testdb_pub ;

Ở trên cũng sẽ sao chép dữ liệu.

Thêm các bảng mà bạn muốn có chỉ mục DUY NHẤT
Chạy cả trong các nút của nhà xuất bản và người đăng ký, ví dụ:

ALTER TABLE someschema.yourtable REPLICA IDENTITY USING INDEX yourindex_ukey;

Trên nhà xuất bản:

ALTER PUBLICATION data_for_testdb_pub ADD TABLE ONLY someschema.yourtable;

Trên người đăng ký:

ALTER SUBSCRIPTION data_for_testdb_pub REFRESH PUBLICATION WITH ( COPY_DATA );

Tại thời điểm này (đồng bộ hóa), bạn phải luôn theo dõi nhật ký PostgreSQL trên nút người đăng ký. Bạn không muốn có bất kỳ lỗi hoặc bất kỳ điều gì (thời gian chờ) ngăn cấm việc tiếp tục sao chép hợp lý. GIẢI QUYẾT MỌI LỖI NGAY LẬP TỨC hoặc nhà xuất bản sẽ tiếp tục tích lũy các tệp WAL trong pg_wal và cuối cùng sẽ hết dung lượng. Vì vậy, bạn phải đối phó với
- Tất cả LỖI hoặc bất kỳ thông báo nào liên quan đến nhân viên logic dẫn đến việc thoát
- Cũng quan tâm đến
  - wal_receiver_timeout
  - wal_sender_timeout

Sau khi giải quyết tất cả các vấn đề, bạn sẽ có nút người đăng ký của mình hoạt động vui vẻ. Vì vậy, câu hỏi tiếp theo là làm thế nào để sử dụng nó như một máy chủ cơ sở dữ liệu thử nghiệm. Bạn sẽ phải đối phó với những vấn đề / sự cố đó:

Ẩn danh
Khóa chính và khóa duy nhất dựa trên vi phạm trình tự
Một tập hợp các phương pháp hay
Giám sát

Ẩn danh

Về việc ẩn danh dữ liệu cá nhân được thực thi bởi GDPR ở Liên minh Châu Âu, bạn nên viết một số trình kích hoạt LUÔN LUÔN để trống tất cả các trường liên quan đến địa chỉ, tài khoản ngân hàng, tình trạng hôn nhân, số điện thoại, email, v.v. Bạn nên tham khảo ý kiến của nhân viên an ninh trong công ty của bạn về những gì cần giữ lại và những gì cần bỏ trống. Các trình kích hoạt phải được định nghĩa là LUÔN LUÔN vì công nhân logic chạy các câu lệnh dưới dạng REPLICA.

Khóa chính với chuỗi

Về trình tự, rõ ràng sẽ có vấn đề với các khóa đó trừ khi được xử lý trước khi bất kỳ thử nghiệm nào được bắt đầu. Hãy xem xét trường hợp này:

Vào chiều thứ Sáu, bạn thực hiện một số bài kiểm tra trên cơ sở dữ liệu người đăng ký khi chèn một hàng mới vào một số bảng. Giá trị này sẽ có dưới dạng ID, giá trị tiếp theo được tạo bởi chuỗi.
Bạn về nhà vào cuối tuần.
Một số người dùng sản xuất nhập một hàng trong cùng một bảng trên cơ sở dữ liệu của nhà xuất bản.
Hàng sẽ được sao chép dựa trên IDENTITY REPLICA tới nút người đăng ký nhưng sẽ không thành công do LỖI vi phạm PK. Trình làm việc nền logic sẽ thoát và thử lại. Nhưng sẽ tiếp tục thất bại chừng nào vấn đề vẫn còn.
Quá trình sao chép sẽ bị kẹt. Khe sao chép sẽ bắt đầu tích lũy WAL.
Nhà xuất bản hết dung lượng đĩa.
Vào cuối tuần, bạn nhận được email cho biết nút Chính của bạn đã PANIC!

Vì vậy, để giải quyết vấn đề về trình tự, bạn có thể thực hiện theo cách sau:

select 'SELECT setval(''' || seqrelid::regclass||''','||CASE WHEN seqincrement <0 THEN -214748364 ELSE 214748364 END||');' from pg_sequence where seqtypid=20;
\gexec

Những gì ở trên làm là đặt các chuỗi thành một giá trị đủ lớn để chúng không bao giờ chồng chéo lên nhau cho một cửa sổ khá lớn trong tương lai, cho phép bạn có một máy chủ thử nghiệm không gặp sự cố.

Một tập hợp các Thực tiễn Tốt

Bạn thực sự nên nói với các lập trình viên của bạn để thực hiện các bài kiểm tra của họ không liên tục. Vì vậy, bất kỳ bài kiểm tra nào sau khi hoàn thành nên để cơ sở dữ liệu ở trạng thái giống như trước khi kiểm tra. Với việc chèn ID dựa trên trình tự, đây không phải là vấn đề, chúng tôi đã thấy một giải pháp trước đó. Nhưng với các khóa không theo trình tự (ví dụ:hợp chất), các khóa UNIQUE có thể là một vấn đề. Vì vậy, tốt nhất là xóa những dữ liệu thử nghiệm đó trước khi một số hàng sản xuất có cùng giá trị truy cập vào bảng đã đăng ký.

Ở đây, chúng ta cũng nên thêm xử lý các thay đổi lược đồ. Tất cả các thay đổi giản đồ cũng phải được thực hiện trên người đăng ký để không phá vỡ lưu lượng DML được sao chép.

Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

Giám sát

Bạn thực sự nên đầu tư vào một giải pháp giám sát tốt. Bạn nên theo dõi ...

Tại người đăng ký:

TẤT CẢ các tin nhắn trong nhật ký của người đăng ký có liên quan đến lối ra của nhân viên logic. Cài đặt một công cụ như tail_n_mail thực sự có thể giúp ích cho việc này. Một cấu hình được xác định là hoạt động:
```
INCLUDE: ERROR:  .*publisher.*
INCLUDE: ERROR:  .*exited with exit.*
INCLUDE: LOG:  .*exited with exit.*
INCLUDE: FATAL:  
INCLUDE: PANIC:
```
Sau khi nhận được cảnh báo từ tail_n_mail, chúng tôi phải giải quyết vấn đề ngay lập tức.
pg_stat_subscription. Pid không được rỗng. Ngoài ra, độ trễ cũng phải nhỏ.

Tại nhà xuất bản:

pg_stat_replication. Điều này phải có nhiều hàng như chúng được cho là:Một hàng cho mỗi chế độ chờ nhân rộng luồng được kết nối (bao gồm các nút thuê bao và các điểm chờ vật lý khác).
pg_replication_slots cho vị trí người đăng ký. Điều này sẽ hoạt động.

Nói chung, phải mất một thời gian cho đến khi bạn có máy chủ cơ sở dữ liệu thử nghiệm lý tưởng của mình chạy mà không gặp sự cố, nhưng khi bạn đã giải quyết tất cả, lập trình viên của bạn sẽ cảm ơn bạn vì đã có nó!