PostgreSQL: Tôi có thể thực hiện pg_start_backup () khi đang chạy db đang chạy không?

Bản sao được thiết lập của chúng tôi đã bị hỏng ("phân đoạn WAL được yêu cầu đã bị xóa" trong thời gian ngừng hoạt động) Chúng tôi không thể dễ dàng dừng lại bản gốc.

Chúng ta có thể làm không

1. pg_start_backup(),
2. rsync ${PGDATA}/ làm chủ nô lệ
3. pg_stop_backup()

... trong khi postgresql chính vẫn còn đầy tải? (Hoặc sẽ pg_start_backup()dẫn đến

• khóa bàn,
• Khối I / O,
• mâu thuẫn,
• chuông báo cháy,
• phản hồi db chậm

Nói cách khác, sẽ pg_start_backup()ảnh hưởng đến ứng dụng của chúng ta?

pg_start_backupsẽ thực hiện một điểm kiểm tra, như ghi chú dezso. Điều này có ảnh hưởng, nhưng dù sao cơ sở dữ liệu của bạn vẫn thực hiện các điểm kiểm tra khá thường xuyên và phải làm như vậy để hoạt động, vì vậy rõ ràng chúng không phải là vấn đề đối với bạn. Một điểm kiểm tra sớm có nghĩa là ít dữ liệu đã được tích lũy, có nghĩa là nếu bất cứ điều gì một điểm kiểm tra từ đó pg_start_backupsẽ có tác động thấp hơn bình thường.

Nơi bạn cần lo lắng là rsync hoặc pg_basebackupbước tương đương . Việc đọc I / O từ điều này sẽ không quá tệ vì nó liên tục, nhưng nó vẫn có thể làm tổn hại đáng kể đến hiệu suất I / O của cơ sở dữ liệu của bạn và nó cũng sẽ có xu hướng đẩy dữ liệu nóng ra khỏi bộ nhớ cache RAM ít hơn dữ liệu được sử dụng, gây ra lỗi bộ đệm khi dữ liệu cần thiết hơn sau đó được đọc lại.

Bạn có thể sử dụng nicevà ioniceđể giúp hạn chế tác động I / O (nhưng không ảnh hưởng đến bộ đệm); tuy nhiên, có một chi phí cho điều đó. Việc sao lưu sẽ mất nhiều thời gian hơn và cho đến khi bạn hoàn thành sao lưu và chạy pg_stop_backuphệ thống của mình - theo tôi hiểu - tích lũy WAL, nó không thể xóa, tích lũy nợ điểm kiểm tra cho điểm kiểm tra LỚN ở cuối quá trình sao lưu và đang tích lũy bảng và chỉ mục phình to vì nó không thể dọn sạch hàng chết. Vì vậy, bạn thực sự không đủ khả năng để sao lưu vĩnh viễn, đặc biệt nếu bạn có các bảng khuấy rất cao.

Cuối cùng, thật khó để nói liệu bạn có thể sử dụng an toàn pg_start_backupvà pg_stop_backupsao lưu dự phòng nóng trong môi trường của mình hay không. Hầu hết mọi người đều có thể, nhưng nếu bạn ở gần rìa của những gì phần cứng của bạn có thể làm, có yêu cầu về thời gian chặt chẽ, không thể chấp nhận rủi ro của một gian hàng và có các bảng khuấy rất cao cũng như các bảng rất lớn, điều đó có thể gây rắc rối .

Thật không may, bạn khá nhiều cần phải kiểm tra nó và xem.

Nếu bạn có thể, có thể đáng để ban hành CHECKPOINTsau đó chụp ảnh nguyên tử cho khối lượng mà cơ sở dữ liệu của bạn đang bật thay vì sử dụng LVM, công cụ SAN của bạn, EBS hoặc bất cứ thứ gì bạn đang sử dụng. Nếu bạn có thể làm điều này, thì bạn có thể sao chép ảnh chụp nhanh lúc rảnh rỗi. Cách tiếp cận này không phù hợp để thực hiện sao lưu cơ sở cho PITR / chế độ chờ ấm / chế độ chờ nóng, nhưng nó hoàn toàn tốt cho bản sao lưu tĩnh và tác động đến hệ thống thấp hơn nhiều. Bạn chỉ có thể làm điều này nếu ảnh chụp nhanh của bạn là nguyên tử và toàn bộ cơ sở dữ liệu của bạn bao gồm WAL nằm trên một tập duy nhất.

Một khả năng tôi chưa điều tra là kết hợp cả hai cách tiếp cận. Nó xảy ra với tôi rằng người ta có thể ( chưa được kiểm tra và có thể sai và không an toàn , tôi chưa biết):

• pg_start_backup
• Ảnh chụp nhanh kích hoạt của tất cả các không gian bảng, datadir chính và âm lượng xlog
• pg_stop_backup
• Sao chép WAL lên đến kho lưu trữ cuối cùng từ pg_stop_backup
• Sao chép dữ liệu từ các khối được chụp

Về cơ bản, ý tưởng là giảm thời gian DB phải trì hoãn các điểm kiểm tra của nó bằng cách lấy thời gian của từng tập mà bạn có thể sao chép tùy ý.

Đây là một đào mộ nhưng tôi phải sửa một cái gì đó ở đây.

Câu trả lời trước đó là:

Bạn có thể sử dụng đẹp và ionice để giúp hạn chế tác động I / O (nhưng không ảnh hưởng đến bộ đệm); tuy nhiên, có một chi phí cho điều đó. Việc sao lưu sẽ mất nhiều thời gian hơn và cho đến khi bạn hoàn thành sao lưu và chạy pg_stop_backup thì hệ thống của bạn - theo tôi hiểu - tích lũy WAL, nó không thể xóa, tích lũy nợ điểm kiểm tra cho điểm kiểm tra LỚN ở cuối quá trình sao lưu và đang tích lũy bảng và chỉ số phình to vì nó không thể dọn sạch các hàng chết. Vì vậy, bạn thực sự không đủ khả năng để sao lưu vĩnh viễn, đặc biệt nếu bạn có các bảng khuấy rất cao.

Đo không phải sự thật. Hệ thống sẽ giữ số WAL được nêu trong cấu hình của bạn (cf tài liệu trực tuyến ). Về cơ bản, giá trị cao hơn giữa:

• (2 + checkpoint_completion_ratio) * checkpoint_segments + 1
• wal_keep_segments

Hãy tưởng tượng trường hợp này:

• sao lưu của bạn mất nhiều thời gian, vì có hàng trăm hợp đồng để sao chép
• bạn có một lưu giữ WAL nhỏ (ví dụ: checkpoint_segments đến 3)
• bạn không thiết lập lưu trữ WAL

sau đó sau khi bắt đầu "pg_start_backup ()", các tệp WAL của bạn sẽ xoay trong khi sao lưu. Khi sao lưu của bạn sẽ kết thúc, sau đó bạn sẽ cố gắng khôi phục nó trên một công cụ cơ sở dữ liệu khác. Công cụ khi khởi chạy sẽ yêu cầu ít nhất tệp WAL được tạo khi bạn phát hành "pg_start_backup ()".

pg_start_backup 
-----------------
B/D0020F18
(1 row)

Cơ sở dữ liệu sẽ không chấp nhận khởi động cho đến khi bạn cung cấp tệp WAL "0000000x0000000B000000D0" (trong đó x là TimelineID của bạn ). Tệp WAL này là mức tối thiểu để hệ thống khởi động. Tất nhiên, chỉ với tệp này, bạn sẽ mất dữ liệu, vì phần còn lại của dữ liệu nằm trong tệp WAL bạn không có, nhưng ít nhất, bạn sẽ có một công cụ cơ sở dữ liệu hoạt động.

Vì vậy, hoặc bạn phải thực hiện lưu trữ WAL hoặc bạn phải tự lưu các tệp WAL cần thiết, nhưng Postgresql sẽ không làm điều đó cho bạn.

Đối với trải nghiệm của tôi với PostgreSQL, đây là hoạt động tương đối an toàn trừ khi bạn có tác động hiệu suất thực sự lớn vào thời điểm đó. Nếu bạn có nó thì tốt hơn là tạm dừng viết từ tất cả các khách hàng của bạn.

Tôi chỉ có một trường hợp quan trọng trong khi đồng bộ hóa chủ nhân của mình thành nô lệ khi tải và nó được gây ra bởi kẻ giết người OOM (vâng, bạn thực sự nên HOÀN TOÀN vô hiệu hóa OOM Killer trên các nút cơ sở dữ liệu, tôi không biết điều đó vào ngày hôm đó).

Vì vậy, tôi đã khôi phục cơ sở dữ liệu từ bản sao lưu hàng đêm và đã gửi cho tất cả các phân đoạn WAL từ thư mục pg_archive để phát lại (chỉ cần sao chép chúng vào thư mục pg_xlog). Tất cả mọi thứ đều ổn, nhưng thời gian chết là không thể tránh khỏi, tất nhiên.