EC2 - Làm cách nào để sao lưu chính xác dữ liệu PostgreSQL?


9

Đây là thiết lập: 1 phiên bản EC2 nhỏ của Amazon Linux (được hỗ trợ bởi EBS) với 3 khối lượng bổ sung. Đây là cả một máy chủ web và máy chủ cơ sở dữ liệu. Một tập cho mã, một tập cho thư mục dữ liệu PostgreSQL (8.4) và một tập để lưu trữ các tệp WAL từ PostgreQuery.

(1) Âm lượng với các tệp WAL cũng sẽ có bản sao lưu cơ sở của thư mục dữ liệu, được sao chép lại sau khi thực hiện pg_start_backup (). Sau đó, nó sẽ lưu trữ đầu ra lưu trữ liên tục từ PostgreSQL (tệp WAL). Để chụp nhanh khối lượng này, có bất kỳ điểm nào trong việc phát hành đồng bộ hóa và đóng băng hệ thống tệp (sử dụng xfs_freeze nếu đó là XFS hoặc dmsetup nếu đó là EXT4)? Hoặc tôi chỉ có thể chụp ảnh trực tiếp? Các tập tin WAL sẽ được vận chuyển với tốc độ một lần mỗi phút. Có thể bắt đầu một ảnh chụp nhanh trong khi một tệp WAL duy nhất đang được sao chép và dẫn đến dữ liệu bị hỏng?

(2) Ổ đĩa chứa thư mục dữ liệu PostgreSQL trực tiếp cũng sẽ được sao lưu để có biện pháp tốt (hàng ngày). Trước khi thực hiện một ảnh chụp nhanh của tập này, tôi đưa ra một pg_dump và tệp SQL kết quả được giữ trong thư mục dữ liệu. Có bất kỳ điểm nào trong việc thực hiện các biện pháp phòng ngừa để đảm bảo dữ liệu cơ sở dữ liệu thực tế là phù hợp? Sẽ là chính xác nếu giả sử rằng chụp ảnh nhanh sẽ đúng (a) các tệp cấu hình sao lưu (postgresql.conf, pg_hba.conf, pg_ident.conf) và (b) sao lưu tệp kết xuất SQL. Sao lưu hai thứ đó, tệp kết xuất sql và tệp cấu hình, sẽ là điểm chính của việc chia nhỏ khối lượng này. DB không lớn lắm nên tôi không bận tâm thực tế là các tệp dữ liệu sẽ làm mờ ảnh chụp nhanh này. Và trong trường hợp đó, tôi chỉ có thể chụp ảnh trực tiếp - đúng không?

(2a) Sẽ tốt hơn nếu giữ thư mục dữ liệu trên ổ đĩa gốc và có tập lệnh sao lưu sao chép tệp kết xuất sql cũng như cấu hình các tệp vào một ổ đĩa khác và chụp nhanh ổ đĩa đó sau khi sao chép xong?

(3) Đối với âm lượng có mã trên đó, một lần nữa có điểm nào trong việc đồng bộ hóa và đóng băng hệ thống tập tin không? Hoặc chỉ có thể chụp ảnh trực tiếp? Dữ liệu này phải khá "tĩnh".

(4) Đây có phải là một kế hoạch dự phòng vững chắc? Âm lượng gốc không được sao lưu thường xuyên vì tôi sẽ chỉ giữ một hình ảnh máy sau khi nó được thiết lập và định cấu hình.

Cảm ơn

Câu trả lời:


13

Xem hướng dẫn sử dụng tốt . Nếu lời khuyên của tôi mâu thuẫn với 'theo bất kỳ cách nào, thì đúng.

  1. Đồng bộ hóa không phải là một ý tưởng tồi, trừ khi công cụ sao chép của bạn fsync () mỗi tệp WAL mà nó ghi và thư mục của nó trước khi sao chép tệp tiếp theo. Một tệp WAL cuối cùng không đầy đủ không quan trọng lắm; tệ nhất, bạn chỉ cần xóa nó. Nói chung, PG sẽ nghẹt thở với một WAL chưa hoàn chỉnh - mặc dù không có kiểm tra nào được thực hiện, vì vậy bạn có thểthực sự không may mắn và hãy thử áp dụng dữ liệu rác mà cơ hội điên rồ đã xảy ra giống như các bản ghi WAL thực sự. Ở vị trí của bạn, tôi sẽ đồng bộ hóa âm lượng trước khi chụp nhanh để đảm bảo mọi bộ đệm bẩn không được ghi trong RAM chạm vào hình ảnh hệ thống tệp trên đĩa. Việc đóng băng sẽ giúp tránh các WALs lộn xộn nhưng không gây tử vong một phần, vì vậy đó không phải là một ý tưởng tồi tệ nhưng không quan trọng. Điều quan trọng là có một dòng thời gian không bị hư hại cho đến thời điểm phục hồi. Cá nhân, tôi viết các WAL của mình thành một tên tệp tạm thời và đổi tên chúng thành tên cuối cùng của chúng chỉ một lần được sao chép hoàn toàn; nếu bạn làm điều này, bạn không cần phải đóng băng.

  2. Âm thanh chính xác. Ảnh chụp nhanh trực tiếp cũng giống như thực hiện kiểm tra kéo cắm trên hệ thống trực tiếp với bộ nhớ đệm ghi. Cơ sở dữ liệu của bạn sẽ phục hồi tốt khi được khôi phục từ ảnh chụp nhanh, giống như sau khi cắm. Tôi khuyên bạn nên tự động hóa các bài kiểm tra khôi phục từ ảnh chụp nhanh. (Lưu ý: Kiểm tra khôi phục ảnh chụp nhanh không phải là sự thay thế hoàn toàn cho kiểm tra kéo cắm vì nó không tính đến đĩa có thể, bộ điều khiển đột kích, v.v. ghi bộ nhớ đệm). Không chỉ các tập tin cấu hình và kết xuất, mà cơ sở dữ liệu tự nó sẽ ổn sau ảnh chụp nhanh của bạn. Cân nhắc đồng bộ hóa âm lượng trước ảnh chụp nhanh để đảm bảo tất cả dữ liệu kết xuất, v.v. đã thực sự chạm đĩa.

    2a. Có thể tiết kiệm một số không gian đĩa. Ít khác biệt. Bạn sẽ có thể giữ các ảnh chụp nhanh hơn rất nhiều mà không cần đến cơ sở dữ liệu trực tiếp trên chúng.

  3. Tại sao thậm chí chụp nhanh khối lượng mã của bạn? Một bản sao mức tập tin đơn giản cũng có thể là tốt. Chắc chắn một bức ảnh chụp trực tiếp nên được.

  4. Đây không phải là một chương trình sao lưu vững chắc. Nó thất bại trong một lĩnh vực quan trọng: Không có kiểm tra khôi phục và xác nhận được thực hiện. Bạn nên thường xuyên kiểm tra các bản sao lưu của mình một cách thường xuyên để đảm bảo bạn có thể thực sự khôi phục chúng.

    Cá nhân, tôi khuyên bạn nên sử dụng vận chuyển WAL hoặc gửi các bãi chứa cơ sở dữ liệu đến một máy chủ khác , tốt nhất là không phải trên Amazon EC2 hoặc ít nhất là ở một khu vực khác. Máy chủ này sẽ thực hiện các kiểm tra khôi phục tự động, gửi báo cáo cho bạn về kết quả và cũng nên được kiểm tra thủ công.

    Mặc dù ảnh chụp nhanh của bạn (chứa các bãi chứa) sẽ ở trên S3 và sẽ an toàn ở đó, điều đó không có nghĩa là chúng sẽ có thể truy cập được khi bạn cần gấp. Khiếu nại về độ bền của Amazon rất yên tâm, nhưng dữ liệu của bạn vẫn có thể an toàn và hoàn toàn không thể truy cập được đối với bạn trong thời gian ngừng hoạt động của dịch vụ S3.


2
+1, đặc biệt là để sao lưu dữ liệu vào một máy khác không có trên Amazon EC2. Loại bỏ càng nhiều điểm thất bại càng thiết thực.
Mike Sherrill 'Nhớ lại mèo'

1
Thông tin hữu ích, cảm ơn. Một điều tôi không nhận được là tại sao bạn nói "tất cả dữ liệu được sao lưu vẫn nằm trên cùng một máy." Ảnh chụp nhanh EBS được lưu trữ trên S3, khẳng định độ bền 99.999999999% (lưu trữ 10.000 đối tượng và dự kiến ​​sẽ có một thất bại trong 10 triệu năm). Tôi hiểu rằng nó được sao chép vào nhiều trung tâm dữ liệu trong cùng một khu vực; bạn có thể sao chép thủ công sang các khu vực khác. Dĩ nhiên, không có gì sai khi lấy một bản sao bên ngoài AWS để duy trì sự độc lập của nhà cung cấp.
Mark Berry

2
@Mark tweet Bạn hoàn toàn đúng - Tôi cho rằng tôi đã hiểu nhầm đó là một phần của lời giải thích khi tôi viết bài này. Tôi sẽ sửa đổi câu trả lời.
Craig Ringer

Tôi đã có một câu hỏi tiếp theo khá chi tiết mà tôi quyết định đăng dưới dạng một câu hỏi mới: dba.stackexchange.com/q/68461/41155 .
Mark Berry
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.