Tính liên tục trong kinh doanh cho cơ sở dữ liệu
Tính liên tục trong kinh doanh đối với cơ sở dữ liệu có nghĩa là cơ sở dữ liệu phải hoạt động liên tục ngay cả trong thời gian xảy ra thảm họa. Bắt buộc phải đảm bảo rằng cơ sở dữ liệu sản xuất luôn sẵn sàng cho các ứng dụng ngay cả trong thời gian xảy ra thảm họa, nếu không, kết cục có thể trở thành một thương vụ đắt đỏ. Các DBA, Kiến trúc sư sẽ cần đảm bảo rằng môi trường cơ sở dữ liệu có thể duy trì các thảm họa và tuân thủ SLA phục hồi sau thảm họa. Để đảm bảo thảm họa không ảnh hưởng đến tính khả dụng của cơ sở dữ liệu, cơ sở dữ liệu phải được định cấu hình để hoạt động kinh doanh liên tục.
Việc định cấu hình cơ sở dữ liệu cho hoạt động kinh doanh liên tục bao gồm rất nhiều công việc kiến trúc, lập kế hoạch, thiết kế và thử nghiệm. Rất nhiều yếu tố như trung tâm dữ liệu và lãnh thổ địa lý của chúng bao gồm cả thiết kế cơ sở hạ tầng được xem xét khi thiết kế và thực hiện chiến lược khôi phục sau thảm họa hiệu quả cho cơ sở dữ liệu. Điều đó giải thích thực tế rằng “ Kinh doanh liên tục =Tránh ngừng hoạt động trong các thảm họa ”.
Để đảm bảo cơ sở dữ liệu sản xuất tồn tại sau thảm họa, trang Khôi phục sau thảm họa (DR) phải được định cấu hình. Các địa điểm sản xuất và DR phải là một phần của hai Trung tâm dữ liệu cách xa nhau về mặt địa lý. Điều này có nghĩa là, cơ sở dữ liệu dự phòng phải được cấu hình tại DR site cho mọi cơ sở dữ liệu sản xuất để các thay đổi dữ liệu xảy ra trên cơ sở dữ liệu sản xuất ngay lập tức được đồng bộ hóa với cơ sở dữ liệu dự phòng thông qua nhật ký giao dịch. Điều này có thể đạt được nhờ khả năng “Sao chép trực tuyến” trong PostgreSQL.
Điều gì cần xảy ra nếu Thảm họa xảy ra với Cơ sở dữ liệu sản xuất (hoặc chính)?
Khi cơ sở dữ liệu sản xuất (chính) gặp sự cố hoặc không phản hồi, cơ sở dữ liệu dự phòng phải được nâng cấp thành cơ sở dữ liệu chính và các ứng dụng phải được trỏ đến cơ sở dữ liệu dự phòng (chính mới) mới được thúc đẩy và tất cả điều đó phải diễn ra tự động trong SLA ngừng hoạt động được chỉ định. Quá trình này được gọi là chuyển đổi dự phòng.
Định cấu hình PostgreSQL để có tính khả dụng cao
Như đã nói ở trên, để đảm bảo rằng PostgreSQL tuân thủ khả năng phục hồi sau thảm họa, trước tiên nó phải được cấu hình với Streaming Replication (cơ sở dữ liệu chủ + dự phòng) và với khả năng tự động thúc đẩy / chuyển đổi dự phòng ở chế độ chờ. Trước tiên, hãy cùng chúng tôi xem xét cách định cấu hình sao chép phát trực tuyến và tiếp theo là quy trình “chuyển đổi dự phòng”.
Định cấu hình cơ sở dữ liệu dự phòng (sao chép trực tuyến)
Nhân rộng luồng là tính năng được tích hợp sẵn của PostgreSQL đảm bảo dữ liệu được sao chép từ cơ sở dữ liệu Chính sang cơ sở dữ liệu Dự phòng thông qua các bản ghi WAL và hỗ trợ cả phương pháp sao chép Không đồng bộ và Đồng bộ. Cách sao chép này khá đáng tin cậy và phù hợp với các môi trường yêu cầu sao chép theo thời gian thực và hiệu suất cao.
Định cấu hình chế độ chờ phát trực tuyến khá đơn giản. Bước đầu tiên là đảm bảo rằng cấu hình cơ sở dữ liệu chính như sau:
Cấu hình bắt buộc cho cơ sở dữ liệu chính
Đảm bảo các tham số sau được định cấu hình trong postgresql.conf trên cơ sở dữ liệu chính. Thực hiện các thay đổi sau đây sẽ yêu cầu khởi động lại cơ sở dữ liệu.
wal_level=logicalTham số wal_level đảm bảo rằng thông tin cần thiết để sao chép được ghi vào các tệp WAL.
max_wal_senders=1 (or any number more than 0)Các bản ghi WAL được vận chuyển bằng quy trình người gửi wal từ cơ sở dữ liệu chính đến cơ sở dữ liệu dự phòng. Vì vậy, thông số trên phải được định cấu hình ở mức tối thiểu là 1. Yêu cầu nhiều hơn giá trị 1 khi nhiều người gửi wal được yêu cầu.
Bật lưu trữ WAL
Không có sự phụ thuộc cứng nào vào Lưu trữ WAL để sao chép trực tuyến. Tuy nhiên, chúng tôi thực sự khuyên bạn nên định cấu hình Lưu trữ WAL vì, nếu chế độ chờ bị trễ và nếu các tệp WAL bắt buộc bị xóa khỏi thư mục pg_xlog (hoặc pg_wal), thì các tệp Lưu trữ sẽ được yêu cầu để chế độ chờ đồng bộ với tệp chính nếu không, chế độ chờ phải được xây dựng lại từ đầu.
archive_mode=on
archive_command=<archive location>Cơ sở dữ liệu chính phải được định cấu hình để chấp nhận các kết nối từ chế độ chờ.
Cấu hình bên dưới phải có trong pg_hba.conf
host replication postgres <standby-database-host-ip>/32 trustBây giờ, hãy sao lưu cơ sở dữ liệu chính và khôi phục lại trên trang DR. Sau khi hoàn tất quá trình khôi phục, hãy xây dựng tệp recovery.conf trong thư mục dữ liệu với nội dung dưới đây:
standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’Bây giờ, khởi động cơ sở dữ liệu chờ. Tính năng sao chép luồng phải được bật. Thông báo dưới đây trong tệp nhật ký postgresql của cơ sở dữ liệu dự phòng xác nhận rằng tính năng sao chép trực tuyến đang hoạt động thành công:
2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG: started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG: redo starts at 127/CD380170Điều đó kết luận rằng một bản sao trực tuyến đầy đủ chức năng đã được thực hiện. Bước tiếp theo để cài đặt / cấu hình repmgr. Trước đó, hãy để chúng tôi hiểu quy trình chuyển đổi dự phòng.
Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thứcChuyển đổi dự phòng là gì?
Chuyển đổi dự phòng xảy ra khi cơ sở dữ liệu chính hoàn toàn không khả dụng do sự cố. Trong quá trình chuyển đổi dự phòng, cơ sở dữ liệu Dự phòng sẽ được nâng cấp để trở thành cơ sở dữ liệu chính mới để các ứng dụng có thể tiếp tục hoạt động kinh doanh.
Tự động chuyển đổi dự phòng
Toàn bộ quá trình chuyển đổi dự phòng phải diễn ra tự động để đảm bảo hoạt động kinh doanh liên tục hiệu quả và điều này chỉ có thể đạt được bằng một số công cụ phần mềm trung gian. Toàn bộ ý tưởng là để tránh sự can thiệp thủ công của các DBA, Nhà phát triển.
Một công cụ giúp thực hiện chuyển đổi dự phòng tự động là “repmgr”.
Hãy để chúng tôi xem xét repmgr và các khả năng của nó.
Repmgr
Repmgr là một công cụ mã nguồn mở được phát triển bởi 2nd Quadrant. Công cụ này giúp thực hiện các hoạt động quản trị cơ sở dữ liệu khác nhau như xây dựng và giám sát sao chép PostgreSQL bao gồm thực hiện các hoạt động chuyển đổi dự phòng tự động trong trường hợp xảy ra thảm họa và cũng giúp thực hiện các hoạt động chuyển đổi.
Repmgr là một công cụ dễ cài đặt và cấu hình cũng không phức tạp. Trước tiên, hãy để chúng tôi xem xét cài đặt:
Cài đặt repmgr
Tải xuống công cụ từ đây.
Mở tarball và thực hiện cài đặt như hình dưới đây:
Tôi đã cài đặt repmgr-4.2.0 trên máy chủ CentOS 7 và tôi đã cài đặt repmgr dựa trên PostgreSQL-11.1. Trước khi cài đặt, hãy đảm bảo thư mục bin PostgreSQL là một phần của $ PATH và thư mục PostgreSQL lib là một phần của $ LD_LIBRARY_PATH. Để hiểu rằng repmgr được cài đặt dựa trên PostgreSQL-11.1, tôi đang hiển thị đầu ra "thực hiện cài đặt" bên dưới:
[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755 repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'Định cấu hình repmgr để chuyển đổi dự phòng tự động
Trước khi xem xét cấu hình “repmgr”, cơ sở dữ liệu phải được định cấu hình với tính năng sao chép trực tuyến mà chúng ta đã thấy trước đó. Để bắt đầu, cả cơ sở dữ liệu (chính và dự phòng) phải được định cấu hình với tham số sau trong postgresql.conf:
Primary
[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr' # (change requires restart)
Standby
[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr' # (change requires restart)
Tham số trên là để kích hoạt daemon “repmgrd”, liên tục chạy trong nền và giám sát việc nhân rộng luồng. Nếu không có tham số này, không thể thực hiện chuyển đổi dự phòng tự động. Thay đổi tham số này sẽ cần khởi động lại cơ sở dữ liệu.
Tiếp theo, xây dựng tệp cấu hình repmgr (ví dụ với tên repmgr.conf) cho cả hai cơ sở dữ liệu. Cơ sở dữ liệu chính phải có tệp cấu hình với các nội dung sau:
node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'Đặt tệp vào thư mục dữ liệu, trong trường hợp này là “/ data / pgdata11”.
Tệp cấu hình cơ sở dữ liệu dự phòng phải có các nội dung sau:
node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'
failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'
monitoring_history=yes
monitor_interval_secs=5
log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG
promote_check_timeout=5
promote_check_interval=1
master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10
Cả hai cơ sở dữ liệu phải được đăng ký với repmgr.
Đăng ký cơ sở dữ liệu chính
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registeredĐăng ký cơ sở dữ liệu dự phòng
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registeredChạy lệnh dưới đây để đảm bảo ghi nhật ký repmgr đang hoạt động.
[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"
Nếu bạn có thể quan sát, tôi đã định cấu hình log_level thành DEBUG để tạo nhật ký chi tiết trong tệp repmgr.conf của chế độ chờ. Kiểm tra nhật ký để biết trạng thái sao chép.
Kiểm tra xem quá trình sao chép có hoạt động như mong đợi hay không bằng cách sử dụng repmgr:
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
1 | node1 | primary | * running | | default | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
2 | node2 | standby | running | node1 | default | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2Thông báo trên xác nhận sao chép đang chạy tốt.
Bây giờ, nếu tôi tắt cơ sở dữ liệu chính, repmgrd daemon sẽ phát hiện lỗi của cơ sở dữ liệu chính và sẽ thúc đẩy cơ sở dữ liệu dự phòng. Hãy để chúng tôi xem điều đó có xảy ra không -Cơ sở dữ liệu chính bị dừng:
[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stoppedCơ sở dữ liệu dự phòng phải được xúc tiến tự động. Các bản ghi repmgr sẽ hiển thị giống nhau:
fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name FROM repmgr.nodes n WHERE n.upstream_node_id = 1 AND n.node_id != 2 AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name FROM repmgr.nodes n WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
"repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primaryChính xác ở trên có nghĩa là, repmgr không thể kết nối với cơ sở dữ liệu chính và sau 5 lần thử không thành công, chế độ chờ được chuyển sang cơ sở dữ liệu chính mới. Dưới đây là nội dung hiển thị nhật ký cơ sở dữ liệu dự phòng (chính mới) được quảng cáo:
2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL: could not connect to the primary server: could not connect to server: Connection refused
Is the server running on host "xxx.xxx.xx.xx" and accepting
TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG: received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG: redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG: last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG: selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG: archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG: checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG: database system is ready to accept connectionsTôi đã chỉ đề cập đến các tham số quan trọng trong tệp cấu hình repmgr. Có rất nhiều thông số khác có thể được sửa đổi để đáp ứng các yêu cầu khác nhau. Các tham số quan trọng khác là tham số replication_lag_ * như được hiển thị bên dưới:
#replication_lag_warning=300 # repmgr node check --replication-lag
#replication_lag_critical=600 #Repmgr sẽ kiểm tra các ngưỡng của các thông số trên trước khi thúc đẩy chế độ chờ. Nếu độ trễ sao chép là rất quan trọng, thì quảng cáo sẽ không tiếp tục. Điều này thực sự tốt vì nếu chế độ chờ được phát huy khi có độ trễ sẽ dẫn đến mất dữ liệu.
Các ứng dụng phải đảm bảo chúng kết nối lại với chế độ chờ mới được khuyến mại thành công với khung thời gian dự kiến. Bộ cân bằng tải sẽ có khả năng chuyển hướng các kết nối ứng dụng khi cơ sở dữ liệu chính không phản hồi. Giải pháp thay thế khác sẽ là sử dụng các công cụ phần mềm trung gian như PgPool-II để đảm bảo tất cả các kết nối được chuyển hướng thành công.
Để đảm bảo cấu trúc tính sẵn sàng cao được triển khai thành công trong quá trình sản xuất, phải thực hiện kiểm tra kỹ lưỡng từ đầu đến cuối của quy trình hoàn chỉnh. Theo kinh nghiệm của tôi, chúng tôi sử dụng thuật ngữ bài tập này là KHOAN. Có nghĩa là, cứ sau khoảng 6 tháng, một thao tác chuyển đổi sẽ được thực hiện để đảm bảo chế độ chờ được thúc đẩy thành công và các kết nối ứng dụng đang kết nối lại với chế độ chờ được khuyến mại thành công. Cơ sở chính hiện có sẽ trở thành chế độ chờ mới. Sau khi thao tác chuyển đổi thành công, các chỉ số sẽ được đưa xuống để xem các SLA được đáp ứng.
Switchover là gì?
Như đã giải thích ở trên, Switchover là một hoạt động được lên kế hoạch trong đó các vai trò của cơ sở dữ liệu Chính và Dự phòng được chuyển sang. Có nghĩa là Chế độ chờ sẽ trở thành chính và chính sẽ trở thành chế độ chờ. Sử dụng repmgr, điều này có thể đạt được. Dưới đây là những gì repmgr thực hiện khi lệnh chuyển đổi được phát hành.
$ repmgr -f /etc/repmgr.conf standby switchover
NOTICE: executing switchover on node "node2" (ID: 2)
INFO: searching for primary node
INFO: checking if node 1 is primary
INFO: current primary node is 1
INFO: SSH connection to host "node1" succeeded
INFO: archive mode is "off"
INFO: replication lag on this standby is 0 seconds
NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
NOTICE: stopping current primary node "node1" (ID: 1)
NOTICE: issuing CHECKPOINT
DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
INFO: checking primary status; 1 of 6 attempts
NOTICE: current primary has been cleanly shut down at location 0/0501460
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
server promoting
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary
INFO: setting node 1's primary to node 2
NOTICE: starting server using "pg_ctl -D '/data/pgdata11' restart"
NOTICE: NODE REJOIN successful
DETAIL: node 1 is now attached to node 2
NOTICE: switchover was successful
DETAIL: node "node2" is now primary
NOTICE: STANDBY SWITCHOVER is completeNgười đại diện khác có thể làm gì?
- Repmgr có thể giúp xây dựng cơ sở dữ liệu dự phòng từ đầu
- Nhiều cơ sở dữ liệu dự phòng có thể được xây dựng với một cơ sở dữ liệu chính đang chạy
- Có thể xây dựng chế độ chờ xếp tầng mà tôi cảm thấy có lợi hơn so với việc định cấu hình nhiều chế độ chờ cho một cơ sở dữ liệu chính
Điều gì sẽ xảy ra nếu cả Chính và Chờ đều hoạt động?
Đây là một tình huống trong đó doanh nghiệp nghĩ đến việc có nhiều trường hợp chờ. Nếu tất cả chúng đều biến mất, thì cách duy nhất là khôi phục cơ sở dữ liệu từ các bản sao lưu. Đây là lý do tại sao một chiến lược sao lưu tốt là bắt buộc. Các bản sao lưu phải được khôi phục thử nghiệm, xác nhận thường xuyên để đảm bảo các bản sao lưu là đáng tin cậy. Thiết kế cơ sở hạ tầng cho các bản sao lưu phải sao cho việc khôi phục và phục hồi các bản sao lưu không được mất nhiều thời gian. Quá trình khôi phục và khôi phục các bản sao lưu phải được hoàn thành trong SLA được chỉ định. SLA để sao lưu được thiết kế theo RTO (Mục tiêu thời gian khôi phục) và RPO (Mục tiêu điểm khôi phục). Có nghĩa là, RTO:thời gian cần thiết để khôi phục và khôi phục bản sao lưu phải có trong SLA và RPO:cho đến thời điểm nào việc khôi phục được thực hiện phải được chấp nhận, nói cách khác, đó là khả năng chịu mất dữ liệu và nói chung các doanh nghiệp nói là 0 mất dữ liệu khoan dung.
Kết luận
- Tính liên tục trong kinh doanh đối với PostgreSQL là một yêu cầu quan trọng đối với các môi trường cơ sở dữ liệu quan trọng. Để đạt được điều này, bạn cần phải lập rất nhiều kế hoạch và chi phí.
- Tài nguyên và Cơ sở hạ tầng phải được sử dụng tối ưu để đảm bảo đưa ra chiến lược khắc phục thảm họa hiệu quả.
- Có thể có những thách thức từ quan điểm chi phí và cần được quan tâm đến
- Nếu ngân sách cho phép, hãy đảm bảo có nhiều trang DR để chuyển đổi dự phòng
- Trong trường hợp cần khôi phục các bản sao lưu, hãy đảm bảo có chiến lược sao lưu tốt.
