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

Cơ chế sao chép vật lý trong PostgreSQL

Postgres đi kèm với các tính năng sao chép vật lý và logic. Đọc để tìm hiểu thêm về các khía cạnh khác nhau của quá trình tái tạo vật lý.

Tái tạo Vật lý

Các phương pháp sao chép vật lý được sử dụng để duy trì bản sao đầy đủ của toàn bộ dữ liệu trong một cụm duy nhất (trong Postgres, một cụm là một tập hợp cơ sở dữ liệu được quản lý bởi một quy trình máy chủ Postgres chính duy nhất được gọi là postmaster ), thường là máy khác. Máy nguồn được gọi là máy chính trong biệt ngữ Postgres và điểm đến được gọi là chế độ chờ .

Chân đế Nóng, Ấm và "Lạnh"

Máy chủ dự phòng được cập nhật càng nhiều càng tốt với thời gian thực chính và cho phép khách hàng thực hiện các giao dịch chỉ đọc được gọi là hot ở chế độ chờ, hay phổ biến hơn là bản sao đọc . Các standbys nóng đã được thêm vàoPostgres trong phiên bản 9, trước đó chỉ có ấm áp chân đế. Chế độ chờ ấm tương tự như chế độ chờ nóng, ngoại trừ việc nó không cho phép khách hàng kết nối với nó.

(Ngoài ra:Các standby nóng không thể thực hiện các truy vấn tạo bảng tạm thời. Đây là một hạn chế của Postgres.)

Chế độ chờ “lạnh” (không phải thuật ngữ chính thức) thường là máy chủ ở chế độ chờ không khởi động cho đến khi chuyển đổi dự phòng. Vì chế độ chờ nguội không hoạt động và không hoạt động, nên có thể xảy ra lỗi khi khởi động, trước tiên nó có thể phải áp dụng các thay đổi đang chờ xử lý trước khi có thể bắt đầu chấp nhận các kết nối máy khách.

Tệp WAL

Trong quá trình hoạt động bình thường, máy chủ PostgreSQL tạo ra một chuỗi các bản ghi WAL (ghi trước nhật ký) có thứ tự. Về cơ bản, đây là một bản ghi các thay đổi, tương tự như Redis ’AOF hoặc MySQL’s binlog. Về cốt lõi, sao chép vật lý là việc vận chuyển các bản ghi này sang một máy khác và yêu cầu quản trị viên đăng ký khác đang chạy ở đó chấp nhận và áp dụng các bản ghi này vào cơ sở dữ liệu địa phương của nó.

Các bản ghi WAL được chia thành các tệp có kích thước bằng nhau (thường là 16MB) được gọi là phân đoạn WAL hoặc chỉ tệp WAL . Các tệp này được tạo trong một thư mục được gọi là pg_wal trong thư mục dữ liệu cụm (pg_wal được gọi là pg_xlog trong các phiên bản Postgres trước 10). Các tệp WAL cũ sẽ bị loại bỏ khi không còn cần thiết nữa (và cũng dựa trên một vài thông số cấu hình).

Chế độ khôi phục

Quản trị viên bưu điện có thể được khởi động ở một chế độ được gọi là chế độ khôi phục , bằng cách đặt tệp cấu hình hợp lệ có tên là recovery.conf trong thư mục dữ liệu cụm. Ở chế độ khôi phục, Postgres sẽ chỉ nhập và áp dụng các tệp WAL được tạo bởi máy chủ aprimary và bản thân nó sẽ không tạo bất kỳ tệp WAL nào. Máy chủ nóng và ấm chạy ở chế độ khôi phục.

Khi khởi động ở chế độ khôi phục, Postgres trước tiên sẽ cố gắng nhập tất cả các tệp WAL có sẵn trong một kho lưu trữ (thêm điều này bên dưới). Khi kho lưu trữ không có thêm bất kỳ tệp WAL nào để cung cấp, nó sẽ cố gắng nhập bất kỳ tệp nào nằm xung quanh pg_wal của init danh mục. Khi những điều đó cũng được thực hiện, nếu một kết nối chính được định cấu hình vàstandby_modeset thành on trong recovery.conf, Postgres sẽ kết nối với bản ghi chính và kéo và áp dụng các bản ghi WAL mới khi chúng được tạo ở bản chính.

Nhật ký Vận chuyển

Hãy tưởng tượng có một trình kích hoạt sẽ được gọi tại máy chủ chính bất cứ khi nào tệp WAL mới được tạo. Sau đó, trình kích hoạt này có thể sao chép tệp WAL mới sang một máy khác bằng say rsync và đặt nó vào pg_wal thư mục của một quản trị viên đăng bài trong chế độ khôi phục. Bạn có thể tạo chế độ chờ như thế này không?

Câu trả lời là có, và thực sự đây là phương pháp tiêu chuẩn trước khi tính năng phát trực tuyến được thêm vào trong Postgres v9. Hoạt động này được gọi là vận chuyển nhật ký .

Trình kích hoạt là một tập lệnh shell, có thể được định cấu hình bằng archive_command. Tên và đường dẫn của tệp WAL có thể được chuyển cho tập lệnh.

Lưu trữ WAL

Thay vì rsync-ing qua tệp WAL, giả sử chúng ta sao chép nó vào bộ chứa S3 hoặc một thư mục được gắn NFS cũng có thể truy cập được từ máy ở chế độ chờ. trở thành một kho lưu trữ và quá trình lưu trữ tệp WAL vào kho lưu trữ được gọi là lưu trữ liên tục hoặc đơn giản là lưu trữ WAL .

Ngược lại của thao tác này - tìm nạp các tệp WAL từ kho lưu trữ vào Postgres ở chế độ arecovery - có thể được định cấu hình bằng cách sử dụngrestore_command. Tương tự như archive_command , đây cũng là đường dẫn đến một tập lệnh shell. Quản trị viên bưu điện đang chạy ở chế độ khôi phục, biết nó muốn tệp WAL nào. Tên của tệp có thể được chuyển sang tập lệnh.

Ví dụ:đây là các lệnh lưu trữ và khôi phục để lưu trữ và tìm nạp các tệp WAL đến và từ một nhóm S3:

archive_command = 's3cmd put %p s3://BUCKET/path/%f' # in postgresql.conf
restore_command = 's3cmd get s3://BUCKET/path/%f %p' # in recovery.conf

Khi khởi động ở chế độ khôi phục, nếu restore_command được định cấu hình, trước tiên Postgres sẽ cố gắng tìm nạp các tệp WAL từ kho lưu trữ.

pg_standby

Trong chế độ khôi phục, Postgres không và không thể biết trước có bao nhiêu tệpWAL đã được tạo cho đến nay. Nếu lệnh restore_command được định cấu hình, Postgres sẽ gọi nó liên tục với các tên tệp WAL lũy tiến (tên theo trình tự có thể đoán trước) cho đến khi lệnh trả về lỗi.

Ví dụ:lệnh khôi phục có thể đáp ứng các yêu cầu đối với tệp WAL 000000010000000000000001 thông qua 00000001000000000000001A nhưng không thành công cho 00000001000000000000001B vì nó không được tìm thấy trong vị trí lưu trữ. Trong trường hợp không có tệp WAL từ các nguồn khác, Postgres sẽ giả định rằng WALfile 00000001000000000000001B vẫn chưa được tạo bởi phần mềm chính và sẽ hoàn tất quá trình khôi phục sau khi áp dụng 00000001000000000000001A .

Hãy xem xét điều gì sẽ xảy ra nếu lệnh khôi phục đợi tệp 00000001000000000000001B để có sẵn, thay vì thoát với lỗi vì không tìm thấy nó. Postgres sẽ tiếp tục chờ lệnh khôi phục và do đó sẽ tiếp tục ở chế độ khôi phục.

Đây là cấu hình hợp lệ và là cách hợp lệ để thiết lập chế độ chờ ấm.

Postgres gửi kèm theo lệnh có tênpg_standby, lệnh này có thể được sử dụng để thiết lập chế độ chờ ấm theo cách này, miễn là kho lưu trữ là một thư mục. pg_standby sẽ đợi tệp khả dụng nếu không tìm thấy tệp đó.

Các lệnh lưu trữ và khôi phục bằng pg_standby sẽ trông giống như sau:

archive_command = 'cp %p /some/path/%f'         # in postgresql.conf
restore_command = 'pg_standby /some/path %f %p' # in recovery.conf

Sao chép truyền trực tuyến

Sau khi xử lý các tệp WAL đã lưu trữ cũng như các tệp trong pg_wal thư mục, Postgres có thể kết nối với máy chủ chính qua mạng và liên tục tìm nạp áp dụng các tệp WAL mới khi chúng được tạo. Tính năng này, được thêm vào Postgres 9, được gọi là sao chép trực tuyến .

Máy chủ chính để kết nối có thể được chỉ định trong tệp recovery.conf:

# recovery.conf
standby_mode = on
primary_conninfo = 'host=10.0.1.10 user=repl password=p@ssw0rd'

Chế độ chờ nóng

Theo mặc định, khi ở chế độ khôi phục, Postgres sẽ không chấp nhận các kết nối máy khách, từ chối chúng với thông báo lỗi "hệ thống cơ sở dữ liệu đang ở chế độ khôi phục". Thêm dòng hot_standby = on trong recovery.conf, bạn có thể tạo các kết nối máy khách Postgresaccept và cho phép chúng thực hiện các giao dịch chỉ đọc:

# recovery.conf
hot_standby = on

Thường không có lý do gì để tắt hot_standby.

Tài liệu PostgreSQL cung cấp thêm thông tin về cách thiết lập và chạy chế độ chờ ở chế độ “chế độ chờ nóng”.

Các vị trí sao chép

Các khe sao chép đã được giới thiệu trong Postgres 9.4. Chúng là một cơ chế theo dõi một cách chính xác và lâu dài xem chế độ chờ đang tụt lại bao xa so với cơ chế chính. Điều này cho phép tổ chức chính đảm bảo rằng các tệp WAL vẫn cần thiết để bắt kịp chuẩn sẽ không bị xóa.

Trước các vị trí sao chép, không thể cho tệp chính xác định điều này và bạn sẽ gặp phải tình huống trong đó chế độ chờ bị mắc kẹt vì tệp WAL mà nó cần đã bị tệp chính xóa. Tất nhiên, các kho lưu trữ của WAL có thể giải quyết vấn đề này. Tuy nhiên, nếu không có kho lưu trữ WAL, lựa chọn duy nhất là xây dựng lại bản sao từ một bản sao lưu mới.

Bạn có thể đọc thêm về các vị trí sao chép tại đây.

Các bước thiết lập chế độ chờ nóng

Hãy xem các bước cần thiết để thiết lập chế độ chờ nóng cho một cơ sở chính hiện có.

1. Tạo người dùng nhân rộng

Đầu tiên, chúng tôi cần một người dùng cho chế độ chờ để kết nối như:

$ psql -p 6000
psql (11.2 (Debian 11.2-1.pgdg90+1))
Type "help" for help.

postgres=# CREATE USER repluser REPLICATION PASSWORD 'p@ssw0rd';
CREATE USER

Và những thay đổi tương ứng trong pg_hba.conf :

# TYPE  DATABASE        USER          ADDRESS        METHOD
host    replication     repluser      standby-ip/32  md5
# (replace standby-ip)

Tất nhiên, bạn có thể sử dụng bất kỳ cơ chế xác thực tiêu chuẩn nào của PostgreSQL. Người dùng cần có đặc quyền sao chép và đăng nhập, đồng thời không yêu cầu quyền truy cập vào bất kỳ cơ sở dữ liệu cụ thể nào.

Đảm bảo tải lại máy chủ chính để các thay đổi đối với pg_hba.conf có hiệu quả.

2. Sao lưu

Chế độ chờ cần bắt đầu từ một bản sao lưu của chính. Bạn có thể và nên làm điều này bằng cách sử dụng pg_basebackup với một vùng sao chép mới:

pg_basebackup -h primary-ip -p 6000 -U repluser -C -S slot_standby1 -R -D standby

Điều này kết nối với chính tại primary-ip:6000 với người dùng mà chúng tôi vừa tạo và sao lưu nó vào thư mục standby . Vị trí sao chép mới slot_standby1 được tạo.

3. Thêm recovery.conf ở chế độ chờ

Chúng tôi sẽ sử dụng vị trí này làm vị trí sao chép dự phòng của mình để có sự liên tục từ bản sao lưu.

Chúng tôi đã hỏi pg_basebackup để tạo recovery.conf cho chúng tôi ở trên (tùy chọn “-R”). Hãy xem xét điều đó:

$ cat standby/recovery.conf
standby_mode = 'on'
primary_conninfo = 'user=repluser password=''p@ssw0rd'' host=primary-ip port=6000 sslmode=prefer sslcompression=0 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'slot_standby1'

Điều đó thực sự khá tốt và chúng tôi không cần phải sửa đổi thêm. Hãy đơn giản khởi động chế độ chờ ngay bây giờ:

o$ pg_ctl -D standby -l log_standby -o --port=6001 start
waiting for server to start.... done
server started
postgres@stg1:/tmp/demo$ cat log_standby
2019-06-19 09:17:50.032 UTC [21733] LOG:  listening on IPv4 address "127.0.0.1", port 6001
2019-06-19 09:17:50.034 UTC [21733] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.6001"
2019-06-19 09:17:50.067 UTC [21734] LOG:  database system was interrupted; last known up at 2019-06-19 09:12:05 UTC
2019-06-19 09:17:50.111 UTC [21734] LOG:  entering standby mode
2019-06-19 09:17:50.119 UTC [21734] LOG:  redo starts at 0/2000028
2019-06-19 09:17:50.120 UTC [21734] LOG:  consistent recovery state reached at 0/20000F8
2019-06-19 09:17:50.120 UTC [21733] LOG:  database system is ready to accept read only connections
2019-06-19 09:17:50.138 UTC [21739] LOG:  started streaming WAL from primary at 0/3000000 on timeline 1

Và thế là xong! Tệp nhật ký chỉ ra rằng bản sao truyền trực tuyến đang hoạt động. Giờ đây, bạn có thể kết nối với chế độ chờ ở cổng 6001, các truy vấn chỉ chạy và xem các thay đổi được sao chép từ phiên bản chính ít nhiều trong thời gian thực.

Các bước tiếp theo

PostgreSQLdocs là nơi tuyệt vời để bắt đầu đào sâu hơn vào tất cả các tính năng liên quan đến sao chép củaPostgres. Bạn sẽ muốn xem xét các chủ đề như sao chép bị trì hoãn, sao chép theo tầng, dự phòng đồng bộ và hơn thế nữa.

Mặc dù Postgres đi kèm với một bộ tính năng ấn tượng, nhưng vẫn có những trường hợp sử dụng không được hỗ trợ. Postgres wikipage này có danh sách các công cụ của bên thứ ba cung cấp chức năng bổ sung liên quan đến sao ché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. Sao lưu PostgreSQL bằng pg_dump và pg_dumpall

  2. Các hàng trùng lặp trong một bảng khóa chính.

  3. Heroku Postgres:psql:FATAL:không có mục nhập pg_hba.conf cho máy chủ

  4. HikariCP - kết nối không khả dụng

  5. Có thể chỉ định lược đồ khi kết nối với postgres với JDBC không?