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

Trong khi thực hiện PITR, liệu có thể Tạm dừng / Tiếp tục trong PostgreSQL không?

Có, thực sự có thể và được xử lý thông minh bởi PostgreSQL. Để demo điều này, trước tiên tôi cần phải học kỹ thuật tiêu chuẩn của Point in Time Recovery trong PostgreSQL. Nhiều Sách / Bài báo / Blog khác nhau được trình diễn rất hay bởi các tác giả phi thường, do đó tôi không đi vào chi tiết cách thực hiện, tuy nhiên, hãy chuyển thẳng đến chủ đề, tức là cách tạm dừng trong khi khôi phục với cùng một kỹ thuật. Có thể cho rằng, tôi đã đưa ra một biểu thức toán học từ PITR là “PITR =(Bản sao lưu hệ thống tệp cuối cùng (LFB) + WAL Archives được tạo sau khi LFB + WAL chưa được lưu trữ trong $ PGDATA / pg_xlogs hiện tại)”. Để hiểu rõ hơn, tôi đã đưa điều này vào biểu đồ, vì thực tế là nó rõ ràng hơn suy nghĩ:(Xin lỗi, blog này hơi dài, vô tình nó đã xảy ra khi đi vào chi tiết của khái niệm)

Các bước PITR, sẽ tiếp theo với những thay đổi nhỏ mà tôi sẽ nói đến ngay sau đây:

Bước 1. Khôi phục bản sao lưu cấp Hệ thống Tệp (FSB) gần đây nhất đến bất kỳ vị trí nào mà quá trình khôi phục được lên kế hoạch thực hiện.
Bước 2. Nếu FSB là tar, thì hãy gỡ nó ra và làm sạch thư mục pg_xlog để lại archive_status. Nếu bản sao lưu đã loại trừ thư mục này, thì hãy tạo thư mục pg_xlog trống trong FSB.
Bước 3. Sao chép WAL chưa được lưu trữ từ cụm $ PGDATA / pg_xlog bị lỗi vào $ FSB / pg_xlog (Bước 2)
Bước 4. Xóa postmaster.pid khỏi thư mục FSB.
Bước 5. Tạo tệp recovery.conf trong thư mục FSB.
Bước 6. Khởi động cụm (FSB).

Chúng ta nên đặt câu hỏi, khi tạm dừng việc khôi phục có cần thiết không ?. Có thể, để ngăn chặn nhiều lần khôi phục cơ sở hoặc khôi phục cuộn về phía trước nhưng hãy kiểm tra giữa hoặc khôi phục dữ liệu hoặc sở thích của bảng cụ thể để xem nó đã khôi phục được bao xa :). Hãy nhớ rằng, tạm dừng trong phục hồi có nghĩa là, nó cho phép kết nối trong khi khôi phục. Để phác thảo điều này, tôi đã tái tạo một tình huống trong biểu đồ về sự cải thiện các hàng cụ thể trong bảng cho đến khi xảy ra lỗi.

Từ sơ đồ trên, các hàng trong bảng DEMO có thể chấp nhận được là 10,00,000 khi sao lưu cấp hệ thống tệp ($ PGDATA) được thực hiện và 40,00,000 hàng trước khi gặp sự cố. Trong máy ảo cục bộ của mình, tôi đã đưa ra tình huống dựa trên cơ sở là TIME thay vì ngày.

Điều kiện tiên quyết:
1. Sao lưu cấp hệ thống tệp khi bảng DEMO có 10,00,000 hàng.
2. Từ thời điểm đó trở đi, WAL Archives trước khi gặp sự cố trong đó bảng DEMO có 40,00,000 hàng.
3. Vị trí Lưu trữ WAL:/opt/PostgreSQL/9.3/archives.
4. Thư mục dữ liệu:/opt/PostgreSQL/9.3/data (PGDATA)
5. Vị trí sao lưu:/opt/PostgreSQL/9.3/backups

Xin lưu ý rằng làm việc với khôi phục tạm dừng cần có các thay đổi bắt buộc trên cụm chính ($ PGDATA) “wal_level” được đặt thành “hot_standby” và trên cụm khôi phục (sao lưu cấp hệ thống tệp) “hot_standby” được đặt thành “BẬT”. Tôi đã thực hiện những thay đổi này đối với cụm chính, khởi động lại cụm để có hiệu lực và bắt đầu sao lưu. Nếu bạn không phiền, hãy ghi chú nó chỉ đơn giản là một bản demo, vì vậy các kho lưu trữ WAL của tôi có thể không phải là một con số khổng lồ vì chúng chỉ có một vài con số. Tôi cũng đã liệt kê các tệp lưu trữ WAL ở đây, được tạo từ thời điểm sao lưu gặp sự cố.

-bash-4.1$ psql -c "select count(*), now() from demo;"
count | now
---------+-------------------------------
1000000 | 2014-04-04 15:06:04.036928-07
(1 row)

-bash-4.1$ pg_basebackup -D /opt/PostgreSQL/9.3/backup/data_pitr -- I have my $PGDATA, $PGUSER, $PGPORT set, so its a straight command in my case
NOTICE: pg_stop_backup complete, all required WAL segments have been archived

Trạng thái hiện tại của các kho lưu trữ WAL và $ PGDATA / pg_xlog

-bash-4.1$ ls -lrth /opt/PostgreSQL/9.3/archives
-rw------- 1 postgres postgres 16M Apr 4 16:01 00000001000000000000001C
-rw------- 1 postgres postgres 16M Apr 4 16:01 00000001000000000000001D
-rw------- 1 postgres postgres 289 Apr 4 16:06 00000001000000000000001E.000000C8.backup
-rw------- 1 postgres postgres 16M Apr 4 16:06 00000001000000000000001E

-bash-4.1$ ls -lrth /opt/PostgreSQL/9.3/data/pg_xlog | tail -4
-rw------- 1 postgres postgres 289 Apr 4 16:06 00000001000000000000001E.000000C8.backup
-rw------- 1 postgres postgres 16M Apr 4 16:06 00000001000000000000001E
-rw------- 1 postgres postgres 16M Apr 4 16:06 00000001000000000000001F
drwx------ 2 postgres postgres 4.0K Apr 4 16:13 archive_status

Tốt thôi, chúng tôi đã có bản sao lưu, hãy CHÈN một vài bản ghi thành ba phần bằng cách ghi chú thời gian, vì vậy sẽ giúp tạm dừng khôi phục và thêm vào đó, bạn có thể xem WAL được tạo ra từ thời FSB.

-bash-4.1$ psql -c "insert into demo values (generate_series(1,1000000));"
INSERT 0 1000000
-bash-4.1$ psql -c "select count(*),now() from demo;"
count | now
---------+-------------------------------
2000000 | 2014-04-04 16:06:34.941615-07
(1 row)
-bash-4.1$ psql -c "insert into demo values (generate_series(1,1000000));"
INSERT 0 1000000
-bash-4.1$ psql -c "select count(*),now() from demo;"
count | now
---------+-------------------------------
3000000 | 2014-04-04 16:10:31.136725-07
(1 row)
-bash-4.1$ psql -c "insert into demo values (generate_series(1,1000000));"
INSERT 0 1000000
-bash-4.1$ psql -c "select count(*),now() from demo;"
count | now
---------+-------------------------------
4000000 | 2014-04-04 16:13:00.136725-07
(1 row)

Kiểm tra số lượng WAL được sản xuất trong quá trình INSERT.

-bash-4.1$ ls -lrth /opt/PostgreSQL/9.3/archives
-rw------- 1 postgres postgres 289 Apr 4 16:06 00000001000000000000001E.000000C8.backup
-rw------- 1 postgres postgres 16M Apr 4 16:06 00000001000000000000001E
-rw------- 1 postgres postgres 16M Apr 4 16:06 00000001000000000000001F
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000020
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000021
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000022
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000023
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000024
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000025
-rw------- 1 postgres postgres 16M Apr 4 16:06 000000010000000000000026
-rw------- 1 postgres postgres 16M Apr 4 16:10 000000010000000000000027
-rw------- 1 postgres postgres 16M Apr 4 16:10 000000010000000000000028
-rw------- 1 postgres postgres 16M Apr 4 16:10 000000010000000000000029
-rw------- 1 postgres postgres 16M Apr 4 16:10 00000001000000000000002A
-rw------- 1 postgres postgres 16M Apr 4 16:13 00000001000000000000002B

Giả sử tại thời điểm này xảy ra lỗi và bạn phải khôi phục bằng cách sử dụng FSB + WAL lưu trữ + WAL không lưu trữ (nếu có). Trong quá trình khôi phục, tôi muốn tạm dừng ba lần để xem mỗi lần khôi phục 20,00,000, 30,00,000 và 40,00,000 hàng của bảng DEMO bằng cách kết nối với cơ sở dữ liệu ở chế độ CHỈ ĐỌC. Đối với mỗi lần tiếp tục khôi phục, cần khởi động lại cụm khôi phục bằng cách chuyển sang dòng thời gian mới trong recovery.conf / recovery_target_time. Ngoài ra, trong $ FSB / postgresql.conf, chúng ta phải đặt hot_standby =bật. Đây là tệp recovery.conf của tôi:

-bash-4.1$ more recovery.conf
pause_at_recovery_target = true
#recovery_target_time = '2014-04-04 16:06:34' # For 2 lakh records
#recovery_target_time = '2014-04-04 16:10:31' # For 3 lakh records
#recovery_target_time = '2014-04-04 16:13:00' # For 4 lakh records
restore_command = 'cp /opt/PostgreSQL/9.3/archives/%f %p'

Hãy bắt đầu khôi phục cho 20,00,000 bản ghi:

-bash-4.1$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_pitr/ start
server starting

Now in logs:

-bash-4.1$ more postgresql-2014-04-04_162524.log
2014-04-04 16:25:24 PDT-24187---[] LOG: starting point-in-time recovery to 2014-02-06 18:48:56-08
2014-04-04 16:25:24 PDT-24187---[] LOG: restored log file "00000001000000000000001E" from archive
2014-04-04 16:25:24 PDT-24187---[] LOG: redo starts at 0/1E0000C8
2014-04-04 16:25:24 PDT-24187---[] LOG: consistent recovery state reached at 0/1E000190
2014-04-04 16:25:24 PDT-24185---[] LOG: database system is ready to accept read only connections
2014-04-04 16:25:24 PDT-24187---[] LOG: restored log file "00000001000000000000001F" from archive
2014-04-04 16:25:24 PDT-24187---[] LOG: restored log file "000000010000000000000020" from archive
2014-04-04 16:25:25 PDT-24187---[] LOG: restored log file "000000010000000000000021" from archive
2014-04-04 16:25:25 PDT-24187---[] LOG: restored log file "000000010000000000000022" from archive
2014-04-04 16:25:25 PDT-24187---[] LOG: recovery stopping before commit of transaction 1833, time 2014-04-04 16:06:23.893487-07
2014-04-04 16:25:25 PDT-24187---[] LOG: recovery has paused
2014-04-04 16:25:25 PDT-24187---[] HINT: Execute pg_xlog_replay_resume() to continue

Tuyệt vời, hãy xem trong nhật ký nó đã tạm dừng và một HINT thông minh yêu cầu tiếp tục. Tại đây, nếu quá trình khôi phục đạt yêu cầu, bạn có thể tiếp tục bằng cách gọi “select pg_xlog_replay_resume ();” (Bạn có thể kiểm tra). Bây giờ chúng ta sẽ không tiếp tục, tuy nhiên hãy kiểm tra số lượng hàng được khôi phục bằng cách kết nối với máy chủ.

-bash-4.1$ psql -c "select count(*),pg_is_in_recovery() from demo;"
count | pg_is_in_recovery
---------+-------------------
2000000 | t
(1 row)

Tốt, nó đã đạt đến điểm và tạm dừng ở nơi tôi yêu cầu. Hãy tiến thêm một bước nữa để khôi phục 30,00,000 hàng. Bây giờ, hãy đặt dòng thời gian tiếp theo trong recovery.conf / recovery_target_time và khởi động lại cụm.

2014-04-04 16:28:40 PDT-24409---[] LOG:  restored log file "00000001000000000000002A" from archive
2014-04-04 16:28:40 PDT-24409---[] LOG: recovery stopping before commit of transaction 1836, time 2014-04-04 16:10:40.141175-07
2014-04-04 16:28:40 PDT-24409---[] LOG: recovery has paused
2014-04-04 16:28:40 PDT-24409---[] HINT: Execute pg_xlog_replay_resume() to continue.

-bash-4.1$ psql -c "select count(*),pg_is_in_recovery() from demo;"
count | pg_is_in_recovery
---------+-------------------
3000000 | t
(1 row)

Tốt…, chúng ta hãy thử lần cuối cùng để tạm dừng ở 40,00,000 hàng.

2014-04-04 20:09:07 PDT-4723---[] LOG:  restored log file "00000001000000000000002B" from archive
cp: cannot stat `/opt/PostgreSQL/9.3/archives/00000001000000000000002C': No such file or directory
2014-04-04 20:09:07 PDT-4723---[] LOG: redo done at 0/2B0059A0
2014-04-04 20:09:07 PDT-4723---[] LOG: last completed transaction was at log time 2014-04-04 16:11:12.264512-07
2014-04-04 20:09:07 PDT-4723---[] LOG: restored log file "00000001000000000000002B" from archive
2014-04-04 20:09:07 PDT-4723---[] LOG: restored log file "00000002.history" from archive
2014-04-04 20:09:07 PDT-4723---[] LOG: restored log file "00000003.history" from archive
2014-04-04 20:09:07 PDT-4723---[] LOG: restored log file "00000004.history" from archive
cp: cannot stat `/opt/PostgreSQL/9.3/archives/00000005.history': No such file or directory
2014-04-04 20:09:07 PDT-4723---[] LOG: selected new timeline ID: 5
cp: cannot stat `/opt/PostgreSQL/9.3/archives/00000001.history': No such file or directory
2014-04-04 20:09:07 PDT-4723---[] LOG: archive recovery complete
2014-04-04 20:09:08 PDT-4721---[] LOG: database system is ready to accept connections
2014-04-04 20:09:08 PDT-4764---[] LOG: autovacuum launcher started

-bash-4.1$ psql -c "select count(*),pg_is_in_recovery() from demo;"
count | pg_is_in_recovery
---------+-------------------
4000000 | f
(1 row)

Rất tiếc, điều gì đã xảy ra, tại sao nó vẫn chưa tạm dừng và nó phàn nàn gì ?. Hãy nhớ rằng, nếu không có bản lưu trữ WAL nào tại thời điểm recovery_target_time thì nó sẽ không tạm dừng và chờ đợi vì nó đã đến điểm cuối cùng và mở cơ sở dữ liệu để ĐỌC / VIẾT. Trong nhật ký, không có nhiều căng thẳng cho thấy nó đang tìm kiếm tệp “00000001000000000000002C” mà không có sẵn, bởi vì tại thời điểm đó cụm đã bị lỗi. Một số có thể không thừa nhận hành vi này nhưng thực tế và có ý nghĩa khi không có bản lưu trữ WAL nào thì không có lý do gì để tạm dừng quá trình khôi phục. Nếu được yêu cầu tạm dừng ngay cả khi không có bản lưu trữ WAL nào, thì hãy sử dụng standby_mode =’on’ (HOT_STANDBY), trong phương pháp này, nó sẽ không hết khả năng khôi phục nhưng hãy đợi WAL Archives.

Hy vọng nó hữu ích.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Các tùy chọn khôi phục thảm họa cho PostgreSQL được triển khai cho một đám mây lai

  2. Cài đặt pg -v 0.17.1

  3. PGError:ERROR:quyền bị từ chối đối với mối quan hệ (khi sử dụng Heroku)

  4. Trừ số năm cho một ngày trong PostgreSQL

  5. So sánh các bảng tạm thời cho PostgreSQL và Oracle GTT