我们具有如下的主从复制配置。
在主控上:
[postgresql.conf
具有如下配置的复制(为简便起见,删除了注释行):]
max_wal_senders = 1
wal_keep_segments = 8
在奴隶上:
与主机上的postgresql.conf
相同。 recovery.conf
看起来像这样:
standby_mode = 'on'
primary_conninfo = 'host=master1 port=5432 user=replication password=replication'
trigger_file = '/tmp/postgresql.trigger.5432'
最初设置时,我们执行了一些简单的测试,并确认复制正常。但是,当我们执行初始数据加载时,只有一些数据将其发送到从属服务器。
奴隶的日志现在充满了如下所示的消息:
< 2015-01-23 23:59:47.241 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1
< 2015-01-23 23:59:47.241 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed
< 2015-01-23 23:59:52.259 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1
< 2015-01-23 23:59:52.260 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed
< 2015-01-23 23:59:57.270 EST >LOG: started streaming WAL from primary at F/52000000 on timeline 1
< 2015-01-23 23:59:57.270 EST >FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000F00000052 has already been removed
[在#postgresql IRC通道上进行了分析和帮助之后,我得出的结论是,从服务器无法跟上主服务器。我提出的解决方案如下。
在主控上:
max_wal_senders=5
wal_keep_segments=4000
。是的,我知道这是很高的,但是我想监视情况,看看会发生什么。我的主人有空。在奴隶上:
pg_hba.conf pg_ident.conf postgresql.conf recovery.conf
)中rm -rf /var/lib/pgsql/9.3/data/*
)。这似乎是pg_basebackup
所必需的。pg_basebackup -h master -D /var/lib/pgsql/9.3/data --username=replication --password
我错过了什么吗?是否有更好的方法使从属设备最新,而不必重新加载所有数据?
非常感谢您的帮助。
[WAL的处理streaming replication的两个重要选项:
[wal_keep_segments
应该设置得足够高,以允许从属设备在合理的滞后后赶上来(例如,高更新量,从属设备离线等)。
archive_mode
启用WAL归档,可用于恢复早于wal_keep_segments
提供的文件。从属服务器仅需要一种检索WAL段的方法。 NFS是最简单的方法,但是只要可以编写脚本,从scp到http到磁带的任何东西都可以使用。
# on master
archive_mode = on
archive_command = 'cp %p /path_to/archive/%f'
# on slave
restore_command = 'cp /path_to/archive/%f "%p"'
当从站无法直接从主站拉出WAL段时,它将尝试使用restore_command
进行加载。您可以使用archive_cleanup_command
设置将从站配置为自动删除段。
如果从属主机和归档服务器之间都缺少其所需的下一个WAL段,则无法始终如一地恢复数据库。合理的[[only选项是清理服务器,然后从新的archive_cleanup_command
重新开始。
注意:1.必须通过pg_basebackup
来关闭从站2.由于查询psql -c "select pg_start_backup('initial_backup');" rsync -cva --inplace --exclude=*pg_xlog* <data_dir> slave_IP_address:<data_dir> psql -c "select pg_stop_backup();"
,主服务器将变为只读3.主服务器可以继续提供只读查询4.在步骤结束时带回奴隶我在产品中这样做,它对我来说很完美。从机和主机同步,没有数据丢失。
service stop
进行后继,以保留该插槽中提到的副本的WAL段。在pg_start_backup
的更多内容>
在主服务器上运行
replication slots
在从属服务器上,添加到https://www.percona.com/blog/2018/11/30/postgresql-streaming-physical-replication-with-slots/下一行
SELECT pg_create_physical_replication_slot('standby_slot');