您好,登錄后才能下訂單哦!
本文小編為大家詳細介紹“PostgreSQL流式復制的方法是什么”,內容詳細,步驟清晰,細節處理妥當,希望這篇“PostgreSQL流式復制的方法是什么”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。
可以進行寫入的服務器。
也稱為讀/寫服務器。
數據與主服務器持續保持同步的服務器。
也稱為備份服務器或副本。
暖備用服務器是在提升為主服務器之前無法連接的服務器。
相比之下,熱備服務器可以接受連接并提供只讀查詢。在接下來的討論中,我們將只關注熱備服務器。
數據寫入主服務器并傳播到從服務器。如果現有主服務器出現問題,其中一臺從服務器將接管并繼續寫入以確保系統的可用性。
WAL 代表Write-Ahead Logging。
它是一個日志文件,所有對數據庫的修改在應用/寫入數據文件之前都會寫入其中。
WAL 用于數據庫崩潰后的恢復,確保數據完整性。
WAL 用于數據庫系統以實現原子性和持久性。
預寫日志記錄用于保持數據庫服務器之間的數據同步。這是通過兩種方式實現的:
WAL 日志文件從主服務器傳送到備用服務器以保持數據同步。
Master可以直接將日志拷貝到備服務器存儲,也可以與備服務器共享存儲。
一個 WAL 日志文件最多可以包含 16MB 的數據。
WAL 文件僅在達到該閾值后才會發送。
這將導致復制延遲,并且如果主服務器崩潰且日志未歸檔,也會增加丟失數據的機會。
WAL 記錄塊由數據庫服務器流式傳輸以保持數據同步。
備用服務器連接到主服務器以接收 WAL 塊。
WAL 記錄在生成時進行流式傳輸。
WAL 記錄的流式傳輸不需要等待 WAL 文件被填充。
與基于文件的日志傳送相比,這允許備用服務器保持更新。
默認情況下,流復制是異步的,即使它也支持同步復制。
這兩種方法各有優缺點。使用基于文件的傳送可實現時間點恢復和連續歸檔,而流可確保備用服務器上的數據即時可用。但是,您可以將 PostgreSQL 配置為同時使用這兩種方法并享受好處。在這篇文章中,我們主要關注流復制以實現 PostgreSQL 高可用性。
在 PostgreSQL 中設置流式復制非常簡單。假設所有服務器上都已經安裝了 PostgreSQL,您可以按照以下步驟開始:
使用該initdb實用程序在主節點上初始化數據庫 。
通過運行以下命令創建具有復制權限的角色/用戶。運行該命令后,您可以通過運行\du 以在 psql 上列出它們來驗證它 。CREATE USER <user_name> REPLICATION LOGIN ENCRYPTED PASSWORD '<password>';
在主 PostgreSQL 配置 (postgresql.conf) 文件中配置與流式復制相關的屬性:
# Possible values are replica|minimal|logical
wal_level = replica
# required for pg_rewind capability when standby goes out of sync with master
wal_log_hints = on
# sets the maximum number of concurrent connections from the standby servers.
max_wal_senders = 3
# The below parameter is used to tell the master to keep the minimum number of
# segments of WAL logs so that they are not deleted before standby consumes them.
# each segment is 16MB
wal_keep_segments = 8
# The below parameter enables read only connection on the node when it is in
# standby role. This is ignored when the server is running as master.
hot_standby = on
在 pg_hba.conf 文件中添加復制條目以允許服務器之間的復制連接:
# Allow replication connections from localhost,
# by a user with the replication privilege.
# TYPE DATABASE USER ADDRESS METHOD
host replication repl_user IPaddress(CIDR) md5
在主節點上重啟 PostgreSQL 服務以使更改生效。
使用該pg_basebackup 實用程序創建主節點的基本備份,并將其用作備用節點 的起點。
# Explaining a few options used for pg_basebackup utility
# -X option is used to include the required transaction log files (WAL files) in the
# backup. When you specify stream, this will open a second connection to the server
# and start streaming the transaction log at the same time as running the backup.
# -c is the checkpoint option. Setting it to fast will force the checkpoint to be
# created soon.
# -W forces pg_basebackup to prompt for a password before connecting
# to a database.
pg_basebackup -D <data_directory> -h <master_host> -X stream -c fast -U repl_user -W
如果不存在,則創建復制配置文件(如果 pg_basebackup 中提供了 -R 選項,則會自動創建):
# Specifies whether to start the server as a standby. In streaming replication,
# this parameter must be set to on.
standby_mode = ‘on’
# Specifies a connection string which is used for the standby server to connect
# with the primary/master.
primary_conninfo = ‘host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=”host_name”’
# Specifies recovering to a particular timeline. The default is to recover along the
# same timeline that was current when the base backup was taken.
# Setting this to latest recovers to the latest timeline found
# in the archive, which is useful in a standby server.
recovery_target_timeline = ‘latest’
啟動待機。
備用配置必須在所有備用服務器上完成。配置完成并啟動備用服務器后,它將連接到主服務器并開始流式傳輸日志。這將設置復制并可以通過運行 SQL 語句進行驗證 SELECT * FROM pg_stat_replication;。
默認情況下,流式復制是異步的。如果您希望使其同步,則可以使用以下參數對其進行配置:
# num_sync is the number of synchronous standbys from which transactions
# need to wait for replies.
# standby_name is same as application_name value in recovery.conf
# If all standby servers have to be considered for synchronous then set value ‘*’
# If only specific standby servers needs to be considered, then specify them as
# comma-separated list of standby_name.
# The name of a standby server for this purpose is the application_name setting of the
# standby, as set in the primary_conninfo of the
# standby’s WAL receiver.
synchronous_standby_names = ‘num_sync ( standby_name [, ...] )’
Synchronous_commit 必須為同步復制設置,這是默認設置。PostgreSQL 為同步提交提供了非常靈活的選項,并且可以在用戶/數據庫級別進行配置。有效值如下:
Off - 甚至在該事務記錄實際刷新到該節點上的 WAL 日志文件之前,事務提交已向客戶端確認。
本地- 只有在將該事務記錄刷新到該節點上的 WAL 日志文件后,才會向客戶端確認事務提交。
Remote_write – 只有在由 指定的服務器synchronous_standby_names 確認事務記錄已寫入磁盤緩存后,才向客戶端確認事務提交 ,但不一定在刷新到 WAL 日志文件后。
On – 只有在 指定的服務器synchronous_standby_names 確認事務記錄刷新到 WAL 日志文件后,才會向客戶端確認事務提交 。
Remote_apply – 只有在由 指定的服務器synchronous_standby_names 確認事務記錄已刷新到 WAL 日志文件并將其應用于數據庫后,才會向客戶端確認事務提交 。
synchronous_commit 在同步復制模式下設置 為 off 或 local 會使其像異步一樣工作,并且可以幫助您獲得更好的寫入性能。但是,這會增加備用服務器上的數據丟失和讀取延遲的風險。如果設置為 remote_apply,它將確保備用服務器上的數據立即可用,但寫入性能可能會降低,因為它應該應用于所有/提到的備用服務器。
如果您計劃使用連續存檔和時間點恢復,則可以啟用存檔模式。雖然流式復制不是強制性的,但啟用存檔模式有額外的好處。如果歸檔模式未開啟,那么我們需要使用復制槽 功能或確保根據負載將wal_keep_segments值設置得足夠高。
讀到這里,這篇“PostgreSQL流式復制的方法是什么”文章已經介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會,如果想了解更多相關內容的文章,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。