Ảnh chụp lưu trữ để sao lưu nhất quán postgresql - khối lượng dữ liệu và nhật ký khác nhau


11

Chúng tôi đang chạy nhiều máy ảo Linux trong môi trường lưu trữ chia sẻ / vmware, mỗi máy chạy phiên bản riêng của postgreQuery (kết hợp giữa 9.0 và 9.3). Hiện tại, toàn bộ VM nằm trên một phân vùng / khối gốc duy nhất và chúng tôi đã thành công lớn (~ 8 năm) khi sử dụng các ảnh chụp nhanh dựa trên lưu trữ của các khối VMFS cơ bản cho quá trình sao lưu / khôi phục (và sao chép vào trang DR của chúng tôi).

Do kiến ​​trúc lưu trữ của chúng tôi, sẽ rất thuận lợi khi tách các tệp WAL postgres thành một ổ đĩa không ghi, chủ yếu ghi vào bộ nhớ cache để cung cấp cho chúng tôi ít bộ đệm hơn ở phía lưu trữ. Với bộ lưu trữ của chúng tôi (Bộ lưu trữ nhanh nhẹn), chúng tôi có thể gán cả hai khối cho một nhóm bảo vệ / ảnh chụp nhanh, nhưng tôi không thể nói với nhà cung cấp của mình rằng các ảnh chụp nhanh sẽ xảy ra cùng lúc trên tất cả các khối trong nhóm bảo vệ - nó có khả năng sẽ xảy ra, nhưng luôn có cơ hội cách nhau một phần nghìn giây.

Cuối cùng, chúng tôi đã chạy một số thử nghiệm, trong khi ghi dữ liệu vào DB nhanh nhất có thể bằng pg_bench. Sau các thử nghiệm, chúng tôi đã khôi phục khối lượng ảnh chụp nhanh của mình và bắt đầu các postgres VM +

  • Ảnh chụp nhanh cả dữ liệu và khối lượng nhật ký gần đồng thời - kết quả: DB đã phục hồi
  • Ảnh chụp dữ liệu trước, khối lượng nhật ký ~ 1 phút sau - kết quả: DB đã phục hồi
  • Khối lượng nhật ký ảnh chụp trước, khối lượng dữ liệu ~ 1 phút sau - kết quả: DB đã phục hồi
  • Khối lượng nhật ký ảnh chụp trước, khối lượng dữ liệu ~ 3 phút sau, sau khi điểm kiểm tra WAL ghi dữ liệu mới vào dữ liệu: kết quả: DB đã phục hồi

Vì vậy, việc kiểm tra dường như cho chúng ta biết chừng nào cả hai ảnh chụp nhanh đều nhất quán ở mức âm lượng và tương đối gần nhau, bạn sẽ có được một bản sao nhất quán của DB, dựa trên thời gian của ảnh chụp nhanh khối lượng WAL / Log.

Câu hỏi của tôi: Điều này có an toàn không? Các trường hợp góc chúng tôi đang thiếu trong thử nghiệm của chúng tôi là gì, và những gì có thể đi sai?

Tài liệu của Postgres cho thấy điều này không an toàn, nhưng thử nghiệm dường như cho thấy nó khá mạnh mẽ: http://www.postgresql.org/docs/9.1/static/backup-file.html

Nếu cơ sở dữ liệu của bạn trải đều trên nhiều hệ thống tệp, có thể không có cách nào để có được các ảnh chụp nhanh được đóng băng đồng thời chính xác của tất cả các khối. Ví dụ: nếu tệp dữ liệu và nhật ký WAL của bạn nằm trên các đĩa khác nhau hoặc nếu không gian bảng nằm trên các hệ thống tệp khác nhau, có thể không thể sử dụng sao lưu ảnh chụp nhanh vì các ảnh chụp nhanh phải đồng thời. Đọc tài liệu hệ thống tệp của bạn rất cẩn thận trước khi tin tưởng vào kỹ thuật chụp nhanh nhất quán trong các tình huống như vậy.

LƯU Ý: Có, chúng tôi biết về các tùy chọn khác để đảm bảo chúng phù hợp, như đưa PostgreSQL vào chế độ sao lưu nóng hoặc sử dụng tích hợp VMware của bộ lưu trữ của chúng tôi để tự kiểm tra VM, nhưng chúng tôi đang tìm giải pháp chỉ lưu trữ để tăng tốc, thuận tiện, và không ảnh hưởng đến khách hàng của chúng tôi.


2
Một bản cập nhật - nhà cung cấp lưu trữ của chúng tôi, Nimble Storage, đã quay lại hôm nay và nói một cách dứt khoát rằng các ảnh chụp nhanh được thực hiện như một phần của nhóm bảo vệ thực sự nhất quán giữa các tập / được thực hiện tại thời điểm CHÍNH XÁC, vì vậy câu hỏi của tôi thực sự được đưa ra vào thời điểm này. Tuy nhiên - tôi vẫn quan tâm nếu có ai có bất kỳ bình luận nào, vì trong thử nghiệm của chúng tôi, Postgres dường như đủ mạnh để tồn tại các ảnh chụp nhanh không được thực hiện cùng một lúc.
Steve R.

Ý bạn là gì khi bạn nói "Khối lượng dữ liệu chụp trước, khối lượng nhật ký ~ 1 phút sau", nếu cả dữ liệu và khối lượng nhật ký nằm trong cùng một nhóm ảnh chụp nhanh, việc này sẽ được thực hiện cùng một lúc. đặt dữ liệu và khối lượng nhật ký vào một nhóm ảnh chụp nhanh và thực hiện ảnh chụp nhanh, sau đó khôi phục DB từ ảnh chụp nhanh đó giống như phục hồi sự cố. Tôi đã thử nghiệm sao lưu dựa trên lưu trữ EMC trước đây với công nghệ chụp nhanh cho Oracle. Nó rất đáng tin cậy.
cổ tích

Câu trả lời:


2

Tài liệu bạn trích dẫn đã nói lên tất cả, nhưng tôi sẽ không trách bạn nếu bạn muốn cố gắng xác minh các khiếu nại của nhà cung cấp về ảnh chụp nhanh được thực hiện cùng một lúc. Có lẽ một cách để khám phá một cái gì đó có thể là để căng thẳng kiểm tra hệ thống WAL cụ thể hơn.

ví dụ: Ngoài các thử nghiệm dựa trên pgbench của bạn, hãy thử thêm các cuộc gọi ngẫu nhiên pg_switch_xlog()để buộc xoay vòng nhật ký, khoảng thời gian điểm kiểm tra ngắn hơn và dài hơn (rút ngắn và kéo dài checkpoint_timeoutcheckpoint_timeout) và thậm chí sử dụng kích thước tệp wal nhỏ hoặc lớn.

Trừ khi tôi thiếu thứ gì đó, vì các ảnh chụp nhanh của bạn không được thực hiện cùng một lúc, tôi sẽ quy các DB được phục hồi của bạn có lẽ là một chút thời gian may mắn. Trong trường hợp cuối cùng, hãy tưởng tượng bạn đã chụp ảnh nhật ký của mình trong khi vị trí xlog hiện tại là, giả sử , 0/A1C0FFEE. Sau đó, bạn có 3 phút tải đặc biệt nặng trên hệ thống, điều này gây ra một chu kỳ đầy đủ thông qua các tệp WAL và DB của bạn hiện tại 0/DEADBEEFkhi chụp ảnh dữ liệu. Khi bạn cố gắng khôi phục, các tệp WAL được ghi vào thời điểm chụp nhanh dữ liệu sẽ không còn nữa và quá trình khôi phục sẽ thất bại.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.