PostgreSQL logical replication: Cách chỉ sao chép dữ liệu bạn cần

Tác giả: Rishika Kasani và Ramdas Gutlapalli
Ngày phát hành: 07 APR 2026
Chuyên mục: Advanced (300), Amazon Aurora, Amazon RDS, PostgreSQL compatible, RDS for PostgreSQL, Technical How-to

Nhiều tổ chức sử dụng PostgreSQL cần sao chép dữ liệu giữa các cơ sở dữ liệu logic PostgreSQL riêng biệt và muốn kiểm soát chính xác những gì được sao chép. Một nền tảng chăm sóc sức khỏe có thể cần gửi dữ liệu cuộc hẹn đến một cơ sở dữ liệu phân tích mà không tiết lộ Thông tin Sức khỏe Được Bảo vệ (PHI). Một ứng dụng phần mềm dưới dạng dịch vụ (SaaS) đa người thuê có thể cần các bản sao đọc riêng biệt chỉ chứa dữ liệu của một khách hàng.

Bắt đầu từ PostgreSQL 15, logical replication gốc hỗ trợ lọc cả cấp cột và cấp hàng trực tiếp trong các publication. Bạn có thể kiểm soát chính xác những cột và hàng nào chảy từ cơ sở dữ liệu nguồn PostgreSQL đến cơ sở dữ liệu đích PostgreSQL, mà không cần middleware hoặc mã tùy chỉnh. Lưu ý rằng đây là giải pháp sao chép từ PostgreSQL sang PostgreSQL, vì vậy cả nguồn và đích phải là các instance PostgreSQL.

Trong bài đăng này, chúng tôi sẽ trình bày cách logical replication với tính năng lọc chi tiết hoạt động trong PostgreSQL, khi nào nên sử dụng và cách triển khai nó bằng cách sử dụng một kịch bản tuân thủ chăm sóc sức khỏe thực tế. Cho dù bạn đang chạy Amazon Relational Database Service (Amazon RDS) for PostgreSQL, Amazon Aurora PostgreSQL-Compatible Edition hay cơ sở dữ liệu PostgreSQL tự quản lý trên một instance Amazon Elastic Compute Cloud (Amazon EC2), cách tiếp cận đều giống nhau.

Cách thức hoạt động của logical replication trong PostgreSQL

Logical replication của PostgreSQL hoạt động trên mô hình publish-subscribe. Cơ sở dữ liệu nguồn tạo một publication định nghĩa dữ liệu cần chia sẻ, và cơ sở dữ liệu đích tạo một subscription kết nối với publication đó và nhận các thay đổi.

Các bước sau đây mô tả cách quá trình này hoạt động:

Cơ sở dữ liệu nguồn ghi tất cả các thay đổi vào Write-Ahead Log (WAL) của PostgreSQL ở cấp độ logic, ghi lại chi tiết cấp hàng.
Một publication hoạt động như một bộ lọc trên WAL. Nó định nghĩa những bảng nào, những cột nào trong các bảng đó và những hàng nào (sử dụng mệnh đề WHERE) nên được phát sóng. Khi một publication được tạo, PostgreSQL không tạo một bộ đệm riêng hoặc bản sao dữ liệu. Thay vào đó, quá trình WAL sender của nguồn đọc WAL, áp dụng các bộ lọc cột và hàng của publication trong bộ nhớ, và chỉ sau đó gửi kết quả đã lọc đến subscriber.
Subscription của cơ sở dữ liệu đích kết nối với nguồn, đọc luồng WAL đã lọc và áp dụng các thay đổi cục bộ.

Điểm mấu chốt là việc lọc xảy ra ở nguồn trước khi dữ liệu rời khỏi instance. Quá trình WAL sender của nguồn giải mã WAL, áp dụng các bộ lọc publication và chỉ gửi dữ liệu phù hợp đến subscriber. Các cột nhạy cảm hoặc các hàng nằm ngoài phạm vi không truyền qua mạng và không bao giờ đến đích.

Hai chế độ lọc

Lọc cấp cột – bạn có thể chỉ định chính xác những cột nào sẽ đưa vào một publication. Ví dụ, bạn có thể sao chép employee_id, name, và department trong khi loại trừ salary và ssn. Bạn định nghĩa điều này bằng một danh sách cột trong câu lệnh CREATE PUBLICATION:
sql CREATE PUBLICATION pub_emp_safe FOR TABLE employees (employee_id, name, department);
Lọc cấp hàng – bạn có thể chỉ định một mệnh đề WHERE để xác định những hàng nào sẽ được sao chép. Ví dụ, bạn có thể sao chép chỉ các đơn hàng từ một khu vực cụ thể hoặc chỉ các sản phẩm đang hoạt động:
sql CREATE PUBLICATION pub_orders_na FOR TABLE orders WHERE (region IN ('US', 'CA', 'MX'));

Bạn cũng có thể kết hợp cả hai trong một publication duy nhất để kiểm soát chi tiết. Tài liệu PostgreSQL về danh sách cột publication bao gồm cú pháp đầy đủ.

Bật logical replication trên các môi trường

Cú pháp SQL cho publication và subscription là giống nhau trên Amazon RDS for PostgreSQL, Amazon Aurora và PostgreSQL tự quản lý. Sự khác biệt duy nhất là cách bạn bật logical replication. Đối với Amazon RDS for PostgreSQL và Amazon Aurora PostgreSQL-Compatible Edition, hãy đặt rds.logical_replication = 1 trong nhóm tham số tùy chỉnh của bạn (cấp instance cho RDS, cấp cluster cho Aurora) và khởi động lại. Đối với PostgreSQL tự quản lý, hãy đặt wal_level = logical trong postgresql.conf và khởi động lại máy chủ. Phần triển khai từng bước sau này trong bài đăng sẽ trình bày chi tiết từng môi trường.

Các trường hợp sử dụng

Cô lập dữ liệu SaaS đa người thuê

Lọc cấp hàng cho phép cô lập dữ liệu sạch theo từng người thuê trên một cơ sở dữ liệu dùng chung. Bạn tạo một publication cho mỗi người thuê với mệnh đề WHERE (tenant_id = 'customer_xyz'), và bản sao của mỗi khách hàng chỉ nhận được các hàng của họ. Thêm một người thuê mới có nghĩa là tạo một publication mới và một subscription mới chỉ với vài câu lệnh SQL, không phải thay đổi kiến trúc.

Hãy lưu ý đến khả năng mở rộng. Mỗi subscription sử dụng một replication slot trên nguồn, tạo ra một quá trình WAL sender chuyên dụng (khoảng 4 MB bộ nhớ mỗi cái). PostgreSQL mặc định 10 replication slot (max_replication_slots) và 10 quá trình WAL sender (max_wal_senders), cả hai đều có thể cấu hình khi khởi động máy chủ. Mỗi slot cũng giữ lại các phân đoạn WAL cho đến khi subscriber tiêu thụ chúng, vì vậy việc sử dụng đĩa WAL có thể tăng lên nếu một subscriber bị chậm. Đối với số lượng người thuê rất lớn (hàng trăm trở lên), hãy cân nhắc nhóm các người thuê nhỏ hơn vào các publication dùng chung để giữ cho việc sử dụng tài nguyên có thể quản lý được.

Phân phối dữ liệu theo khu vực cho thương mại điện tử

Lọc cấp hàng cho phép các trung tâm thực hiện đơn hàng theo khu vực chỉ nhận dữ liệu đơn hàng cho khu vực địa lý của họ. Ví dụ, một trung tâm ở Bắc Mỹ chỉ nhận các đơn hàng của Hoa Kỳ, Canada và Mexico, trong khi Châu Âu và Châu Á-Thái Bình Dương mỗi nơi nhận các khu vực tương ứng của họ. Mỗi khu vực thường giữ 15-30% tổng số đơn hàng, giảm khối lượng sao chép và chi phí lưu trữ từ 60-80%.

Tuân thủ PCI DSS trong dịch vụ tài chính

Các bộ xử lý thanh toán cần phân tích các mẫu giao dịch (số tiền, dấu thời gian, ID người bán) mà không lưu trữ toàn bộ Số tài khoản chính (PAN) hoặc mã CVV. Lọc cấp cột sao chép siêu dữ liệu giao dịch trong khi loại trừ hoàn toàn các cột dữ liệu chủ thẻ bị hạn chế, giảm phạm vi PCI DSS trên hệ thống đích.

Môi trường phát triển và thử nghiệm

Lọc cấp cột cung cấp một luồng dữ liệu sản xuất trực tiếp, được cập nhật liên tục trừ đi các cột nhạy cảm. Các nhà phát triển nhận được khối lượng dữ liệu, mối quan hệ và phân phối thực tế mà không thấy PII của khách hàng và vì đây là sao chép trực tiếp chứ không phải một công việc hàng loạt hàng đêm, dữ liệu luôn được cập nhật.

Sao chép tồn kho hoạt động trong bán lẻ

Các chuỗi bán lẻ với danh mục lớn (hơn 500.000 SKU) có thể sử dụng lọc cấp hàng với mệnh đề WHERE (status = 'active' AND (qty_on_hand > 0 OR qty_on_order > 0)) để mỗi cửa hàng chỉ nhận 50.000-80.000 SKU đang hoạt động mà họ cần – giảm 80-90% dữ liệu sao chép.

Tuân thủ dữ liệu y tế (HIPAA)

Các tổ chức chăm sóc sức khỏe xử lý dữ liệu cực kỳ nhạy cảm: số An sinh xã hội, mã chẩn đoán, lịch sử thuốc và chi tiết bảo hiểm. Với lọc cấp cột, bạn có thể sao chép dữ liệu hoạt động (ngày hẹn, ID bác sĩ, số tiền thanh toán, mã thủ tục) trong khi giữ các cột PHI (tên bệnh nhân, SSN, mã chẩn đoán, ID bảo hiểm) trên nguồn. Cơ sở dữ liệu phân tích không thấy bất kỳ SSN nào, và vì dữ liệu nhạy cảm không rời khỏi nguồn, các yêu cầu về dấu vết kiểm toán được đơn giản hóa.

Hướng dẫn sau đây triển khai trường hợp sử dụng chăm sóc sức khỏe này.

Điều kiện tiên quyết

Trước khi bắt đầu, hãy đảm bảo rằng bạn có những điều sau:

PostgreSQL 15 trở lên cho cả nguồn và đích. Lọc cấp cột và lọc mệnh đề WHERE cấp hàng trong các publication đã được giới thiệu trong PostgreSQL 15.0 và có sẵn trong tất cả các phiên bản nhỏ tiếp theo. Nguồn và đích không cần chạy cùng một phiên bản chính, nhưng cả hai phải là PostgreSQL 15 trở lên để hỗ trợ các tính năng này. Kiểm tra ghi chú phát hành RDS PostgreSQL15 để biết danh sách tính năng đầy đủ.
Kết nối mạng giữa các instance nguồn và đích. Đích phải có khả năng tiếp cận nguồn trên cổng 5432 (hoặc cổng PostgreSQL đã cấu hình của bạn). Đối với RDS/Aurora, đảm bảo rằng các security group của bạn cho phép lưu lượng truy cập đến từ IP hoặc security group của đích. Xem cấu hình security group của RDS.
Một người dùng PostgreSQL có quyền replication trên nguồn. Người dùng cần vai trò rds_replication (đối với RDS/Aurora) hoặc thuộc tính REPLICATION (đối với tự quản lý). Người dùng này cũng cần quyền SELECT trên các bảng đang được publish.
Logical replication được bật trên instance nguồn:
- RDS/Aurora: Đặt rds.logical_replication = 1 trong nhóm tham số tùy chỉnh của bạn (đối với RDS) và khởi động lại.
- Tự quản lý: Đặt wal_level = logical trong postgresql.conf và khởi động lại.
Đủ khả năng giữ lại WAL. Các logical replication slot giữ lại các phân đoạn WAL cho đến khi tất cả các subscriber tiêu thụ chúng. Theo dõi việc sử dụng đĩa, đặc biệt nếu subscriber ngoại tuyến trong thời gian dài. Đối với RDS, tham số max_slot_wal_keep_size có thể giới hạn việc giữ lại WAL. Xem quản lý replication slot trên RDS.
Một client PostgreSQL như psql để kết nối với cả instance nguồn và đích. Bạn có thể cài đặt và chạy psql từ một instance Amazon EC2 trong cùng VPC với cơ sở dữ liệu của bạn. Ngoài ra, bạn có thể khởi chạy AWS CloudShell ở chế độ VPC trong cùng VPC và cài đặt psql ở đó.

Triển khai từng bước: Ví dụ về tuân thủ y tế

Hãy triển khai trường hợp sử dụng tuân thủ HIPAA. Chúng ta sẽ thiết lập một cơ sở dữ liệu nguồn với dữ liệu cuộc hẹn của bệnh nhân và chỉ sao chép các cột không phải PHI đến một đích phân tích.

Bước 1: Bật logical replication trên nguồn

Đối với Amazon RDS for PostgreSQL:

Sửa đổi nhóm tham số DB tùy chỉnh của bạn để bật logical replication:
bash aws rds modify-db-parameter-group \ --db-parameter-group-name <your-parameter-group-name> \ --parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot"
Khởi động lại instance DB để áp dụng thay đổi:
bash aws rds reboot-db-instance \ --db-instance-identifier <your-db-instance-id>
Kết nối với instance nguồn và xác minh rằng logical replication đang hoạt động:
sql SHOW wal_level;
Bạn sẽ thấy logical trong đầu ra.

Đối với Amazon Aurora PostgreSQL-Compatible Edition:

Sửa đổi nhóm tham số DB cluster tùy chỉnh của bạn:
bash aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name <your-cluster-parameter-group-name> \ --parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot"
Khởi động lại instance writer của cluster:
bash aws rds reboot-db-instance \ --db-instance-identifier <your-writer-instance-id>
Kết nối với instance writer và xác minh:
sql SHOW wal_level;

Đối với PostgreSQL tự quản lý:

Chỉnh sửa postgresql.conf và đặt:
wal_level = logical
Khởi động lại dịch vụ PostgreSQL:
bash sudo systemctl restart postgresql
Kết nối và xác minh:
sql SHOW wal_level;

Bước 2: Tạo bảng nguồn

Kết nối với cơ sở dữ liệu nguồn của bạn và tạo bảng cuộc hẹn bệnh nhân. Bảng này chứa cả dữ liệu hoạt động và PHI:

			
CREATE TABLE patient_appointments (
    appointment_id   SERIAL PRIMARY KEY,
    patient_id       INTEGER NOT NULL,
    patient_name     VARCHAR(100),          -- PHI: exclude from replication
    ssn              VARCHAR(11),           -- PHI: exclude from replication
    date_of_birth    DATE,                  -- PHI: exclude from replication
    diagnosis_code   VARCHAR(10),           -- PHI: exclude from replication
    appointment_date DATE NOT NULL,
    doctor_id        INTEGER NOT NULL,
    department       VARCHAR(50),
    billing_amount   DECIMAL(10,2),
    procedure_code   VARCHAR(10),
    visit_type       VARCHAR(20)
);

		

Một lưu ý về kiểu dữ liệu: kiểu dữ liệu cột của bảng đích phải khớp hoặc tương thích với nguồn. Logical replication truyền dữ liệu ở định dạng văn bản, vì vậy đích áp dụng các hàm nhập kiểu PostgreSQL tiêu chuẩn để phân tích các giá trị đến. Các kiểu không khớp (ví dụ: VARCHAR trên nguồn và INTEGER trên đích) sẽ gây ra lỗi replication. Nếu bạn đang sao chép giữa các phiên bản chính khác nhau của PostgreSQL, hãy xác minh rằng hành vi kiểu dữ liệu không thay đổi. Tài liệu logical replication của PostgreSQL về lọc hàng bao gồm danh sách cột và yêu cầu kiểu chi tiết.

Bước 3: Chèn dữ liệu mẫu

Điền dữ liệu vào bảng với các bản ghi thử nghiệm trải rộng nhiều phòng ban và bác sĩ:

			
INSERT INTO patient_appointments
    (patient_id, patient_name, ssn, date_of_birth, diagnosis_code,
     appointment_date, doctor_id, department, billing_amount, procedure_code, visit_type)
VALUES
    (1001, 'John Smith',    '123-45-6789', '1985-03-15', 'J06.9',  '2025-01-10', 201, 'General Medicine',   150.00, 'CPT99213', 'Follow-up'),
    (1002, 'Jane Doe',      '987-65-4321', '1990-07-22', 'M54.5',  '2025-01-10', 202, 'Orthopedics',        275.00, 'CPT99214', 'New Patient'),
    (1003, 'Robert Brown',  '456-78-9012', '1978-11-03', 'I10',    '2025-01-11', 201, 'General Medicine',   125.00, 'CPT99212', 'Follow-up'),
    (1004, 'Emily Wilson',  '321-54-9876', '1995-01-28', 'K21.0',  '2025-01-11', 203, 'Gastroenterology',   350.00, 'CPT99215', 'New Patient'),
    (1005, 'Michael Lee',   '654-32-1098', '1982-09-14', 'J45.20', '2025-01-12', 204, 'Pulmonology',        200.00, 'CPT99213', 'Follow-up'),
    (1006, 'Sarah Johnson', '789-01-2345', '1988-05-30', 'E11.9',  '2025-01-12', 201, 'General Medicine',   175.00, 'CPT99214', 'Follow-up'),
    (1007, 'David Garcia',  '234-56-7890', '1972-12-08', 'M79.3',  '2025-01-13', 202, 'Orthopedics',        300.00, 'CPT99214', 'Follow-up'),
    (1008, 'Lisa Martinez', '567-89-0123', '1999-04-17', 'J06.9',  '2025-01-13', 204, 'Pulmonology',        150.00, 'CPT99213', 'New Patient');

		

Bước 4: Tạo publication với lọc cột

Bây giờ, tạo một publication chỉ bao gồm các cột không phải PHI. Các cột patient_name, ssn, date_of_birth, và diagnosis_code bị loại trừ bằng cách chỉ liệt kê các cột mà chúng ta muốn sao chép:

			
CREATE PUBLICATION pub_appointments_analytics
FOR TABLE patient_appointments (
    appointment_id, patient_id, appointment_date, doctor_id,
    department, billing_amount, procedure_code, visit_type
);

		

Xác minh rằng publication đã được tạo đúng cách:

			
SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

Các chế độ xem danh mục hệ thống pg_publication và pg_publication_tables là nơi bạn có thể kiểm tra những gì đang được publish.

Tại thời điểm này, publication chỉ là siêu dữ liệu. Nó định nghĩa những gì cần sao chép nhưng không bắt đầu di chuyển dữ liệu. Chưa có replication slot nào tồn tại và không có giải mã WAL nào đang diễn ra. Dữ liệu sẽ chỉ bắt đầu chảy sau khi một subscriber tạo một subscription cho publication này ở Bước 6.

Bước 5: Tạo bảng đích

Kết nối với cơ sở dữ liệu đích (phân tích) PostgreSQL của bạn và tạo một bảng khớp. Bảng phải bao gồm ít nhất các cột được định nghĩa trong publication:

			
CREATE TABLE patient_appointments (
    appointment_id   SERIAL PRIMARY KEY,
    patient_id       INTEGER NOT NULL,
    appointment_date DATE NOT NULL,
    doctor_id        INTEGER NOT NULL,
    department       VARCHAR(50),
    billing_amount   DECIMAL(10,2),
    procedure_code   VARCHAR(10),
    visit_type       VARCHAR(20)
);

		

Lưu ý rằng bảng này chỉ có tám cột không phải PHI. Bạn cũng có thể tạo bảng đầy đủ 12 cột. Các cột không được sao chép sẽ vẫn là NULL, nhưng việc chỉ định các cột bạn cần sẽ làm rõ mục đích và ngăn chặn việc điền dữ liệu ngẫu nhiên sau này.

Bước 6: Tạo subscription trên đích

			
CREATE SUBSCRIPTION sub_appointments_analytics
CONNECTION 'host=<source-endpoint> port=5432 dbname=<dbname> user=<replication_user> password=<password>'
PUBLICATION pub_appointments_analytics;

Thay thế <source-endpoint>, <dbname>, <replication_user>, và <password> bằng thông tin kết nối thực tế của bạn.

Subscription sẽ ngay lập tức bắt đầu đồng bộ hóa bảng ban đầu, sao chép tất cả các hàng hiện có (được lọc bởi danh sách cột của publication) đến đích. Sau khi đồng bộ hóa ban đầu, nó chuyển sang chế độ streaming và áp dụng các thay đổi gần như thời gian thực.

Bạn có thể theo dõi trạng thái subscription bằng cách sử dụng chế độ xem pg_stat_subscription:

SELECT * FROM pg_stat_subscription;

Bước 7: Xác minh quá trình sao chép

Trên đích, truy vấn dữ liệu đã sao chép:

SELECT * FROM patient_appointments ORDER BY appointment_id;

Đầu ra dự kiến:

			
appointment_id | patient_id | appointment_date | doctor_id |    department      | billing_amount | procedure_code | visit_type
----------------+------------+------------------+-----------+--------------------+----------------+----------------+------------
              1 |       1001 | 2025-01-10       |       201 | General Medicine   |         150.00 | CPT99213       | Follow-up
              2 |       1002 | 2025-01-10       |       202 | Orthopedics        |         275.00 | CPT99214       | New Patient
              3 |       1003 | 2025-01-11       |       201 | General Medicine   |         125.00 | CPT99212       | Follow-up
              4 |       1004 | 2025-01-11       |       203 | Gastroenterology   |         350.00 | CPT99215       | New Patient
              5 |       1005 | 2025-01-12       |       204 | Pulmonology        |         200.00 | CPT99213       | Follow-up
              6 |       1006 | 2025-01-12       |       201 | General Medicine   |         175.00 | CPT99214       | Follow-up
              7 |       1007 | 2025-01-13       |       202 | Orthopedics        |         300.00 | CPT99214       | Follow-up
              8 |       1008 | 2025-01-13       |       204 | Pulmonology        |         150.00 | CPT99213       | New Patient

		

Tất cả tám hàng đều có mặt với tám cột hoạt động. Không có tên bệnh nhân, SSN, ngày sinh hoặc mã chẩn đoán nào xuất hiện trên đích. Nhóm phân tích giờ đây có thể chạy các truy vấn như:

			
-- Appointment volume by department
SELECT department, COUNT(*) AS total_appointments, SUM(billing_amount) AS total_billing
FROM patient_appointments
GROUP BY department
ORDER BY total_appointments DESC;
-- Doctor workload analysis
SELECT doctor_id, COUNT(*) AS appointments, AVG(billing_amount) AS avg_billing
FROM patient_appointments
GROUP BY doctor_id
ORDER BY appointments DESC;

		

Bước 8: Kiểm tra quá trình sao chép liên tục

Trở lại nguồn, chèn một bản ghi mới:

			
INSERT INTO patient_appointments
    (patient_id, patient_name, ssn, date_of_birth, diagnosis_code,
     appointment_date, doctor_id, department, billing_amount, procedure_code, visit_type)
VALUES
    (1009, 'Anna Taylor', '890-12-3456', '1991-06-25', 'N39.0',
     '2025-01-14', 203, 'Gastroenterology', 225.00, 'CPT99213', 'Follow-up');

		

Trong vòng vài giây, truy vấn đích:

SELECT * FROM patient_appointments WHERE patient_id = 1009;

Bạn sẽ thấy hàng mới chỉ với tám cột hoạt động. Các trường PHI – patient_name, ssn, date_of_birth, và diagnosis_code không được chuyển đến đích. Các thay đổi đang diễn ra (INSERTs, UPDATEs, DELETEs) trên nguồn được sao chép liên tục với cùng một bộ lọc cột được áp dụng.

Lưu ý về các hạn chế

Logical replication với tính năng lọc chi tiết rất mạnh mẽ, nhưng đáng để biết một vài hạn chế trước khi bạn sử dụng hoàn toàn:

Replica identity: Để replication UPDATE và DELETE hoạt động chính xác, bảng được publish cần có một replica identity. Mặc định là khóa chính hoạt động trong hầu hết các trường hợp. Nếu bạn đang lọc các cột và cột khóa chính của bạn không được bao gồm trong publication, các hoạt động UPDATE và DELETE sẽ thất bại với lỗi vì PostgreSQL không thể xác định hàng nào cần sửa đổi trên đích.
Các thay đổi DDL không được sao chép: Các thay đổi schema (chẳng hạn như ALTER TABLE) không tự động chảy qua logical replication. Bạn phải áp dụng chúng thủ công trên đích trước khi chúng có hiệu lực trên nguồn, nếu không replication sẽ bị hỏng. Xem tài liệu về các hạn chế của logical replication để biết danh sách đầy đủ.
Sequences không được sao chép: Các PostgreSQL sequences là các bộ đếm tự động tăng thường được sử dụng để tạo ID duy nhất cho các cột khóa chính (ví dụ: với các cột SERIAL hoặc IDENTITY). Logical replication sao chép các giá trị ID được tạo dưới dạng dữ liệu nhưng không đồng bộ hóa trạng thái sequence. Điều này có nghĩa là các bộ đếm sequence của cơ sở dữ liệu đích có thể không đồng bộ với dữ liệu thực tế. Nếu bạn thăng cấp cơ sở dữ liệu đích trở thành primary mới (ví dụ: trong kịch bản khôi phục sau thảm họa), bạn phải thủ công tăng các sequence trên đích lên các giá trị cao hơn các ID đã sao chép tối đa, nếu không các bản chèn mới sẽ thất bại với lỗi khóa trùng lặp.
Chi phí hiệu suất: Đồng bộ hóa bảng ban đầu có thể mất đáng kể thời gian đối với các bảng lớn và tạo tải đọc trên nguồn. Cân nhắc lên lịch trong giờ thấp điểm và theo dõi tiến độ đồng bộ hóa bằng cách sử dụng pg_subscription_rel. Ngoài đồng bộ hóa ban đầu, replication đang diễn ra cũng tiêu thụ tài nguyên trên nguồn: mỗi subscription đang hoạt động chạy một quá trình WAL sender chuyên dụng liên tục giải mã các mục WAL và áp dụng các bộ lọc publication. Điều này làm tăng chi phí CPU tỷ lệ thuận với khối lượng ghi trên các bảng được publish. Đối với các khối lượng công việc có thông lượng cao, hãy theo dõi mức sử dụng CPU trên nguồn và cân nhắc mở rộng quy mô nếu các quá trình WAL sender tiêu thụ một phần đáng kể CPU có sẵn.

Dọn dẹp

Khi bạn đã hoàn tất thử nghiệm, hãy xóa các tài nguyên replication để tránh chi phí không cần thiết và tích lũy WAL.

Trên đích, hãy xóa subscription trước:

DROP SUBSCRIPTION sub_appointments_analytics;

Trên nguồn, hãy xóa publication:

DROP PUBLICATION pub_appointments_analytics;

Xóa các bảng thử nghiệm trên cả nguồn và đích:

DROP TABLE IF EXISTS patient_appointments;

Nếu bạn đã tạo các instance RDS hoặc Aurora chuyên dụng cho hướng dẫn này, hãy xóa chúng thông qua AWS Management Console hoặc CLI để ngừng phát sinh chi phí. Nếu bạn đã sửa đổi một nhóm tham số hiện có, hãy cân nhắc hoàn nguyên rds.logical_replication về 0 nếu bạn không còn cần logical replication, và khởi động lại instance.

Kết luận

Với logical replication gốc của PostgreSQL, bạn có thể kiểm soát chính xác dữ liệu nào chảy giữa các cơ sở dữ liệu xuống đến các cột và hàng cụ thể mà không cần bất kỳ công cụ hoặc middleware bên ngoài nào. Lọc cấp cột giữ dữ liệu nhạy cảm như PHI và số thẻ thanh toán hoàn toàn không có trên các hệ thống đích, trong khi lọc cấp hàng cho phép cô lập dữ liệu sạch cho các kiến trúc đa người thuê, phân phối theo khu vực và phân vùng theo thời gian.

Điểm mấu chốt: logical replication với kiểm soát chi tiết chuyển việc lọc dữ liệu từ lớp ứng dụng vào chính công cụ cơ sở dữ liệu. Điều này có nghĩa là ít thành phần di chuyển hơn, ít mã cần bảo trì hơn và khả năng cao hơn là dữ liệu bị hạn chế không rời khỏi nguồn. Cho dù bạn đang hướng tới tuân thủ HIPAA, chứng nhận PCI DSS hay cố gắng cung cấp cho các nhà phát triển dữ liệu giống như sản xuất mà không gặp rắc rối về bảo mật, các publication với danh sách cột và mệnh đề WHERE là một công cụ mạnh mẽ đã được tích hợp sẵn trong PostgreSQL 15 trở lên.

Về tác giả

Ramdas Gutlapalli

Ramdas là Kỹ sư Cơ sở dữ liệu tại AWS. Anh ấy cũng là Chuyên gia về AWS DMS và Amazon RDS for Oracle. Anh ấy sở hữu 11 Chứng chỉ AWS. Anh ấy giúp các khách hàng doanh nghiệp tối ưu hóa cơ sở dữ liệu của họ trên AWS, cung cấp hướng dẫn chuyên môn cho việc di chuyển lên đám mây và cải tiến kỹ thuật.

Rishika Kasani

Rishika là Kỹ sư Hỗ trợ Đám mây tại AWS. Cô ấy là Chuyên gia về Amazon RDS PostgreSQL và AWS DMS, sở hữu ba chứng chỉ AWS. Rishika làm việc chặt chẽ với khách hàng để khắc phục sự cố và giải quyết các vấn đề liên quan đến cơ sở dữ liệu.