如何修复跟不上Master的PostgreSQL 9.3 Slave?

问题描述 投票:15回答:4

我们具有如下的主从复制配置。

在主控上:

[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通道上进行了分析和帮助之后,我得出的结论是,从服务器无法跟上主服务器。我提出的解决方案如下。

在主控上:

  1. 设置max_wal_senders=5
  2. 设置wal_keep_segments=4000。是的,我知道这是很高的,但是我想监视情况,看看会发生什么。我的主人有空。

在奴隶上:

  1. 将配置文件保存在数据目录(即pg_hba.conf pg_ident.conf postgresql.conf recovery.conf)中
  2. 清除数据目录(rm -rf /var/lib/pgsql/9.3/data/*)。这似乎是pg_basebackup所必需的。
  3. 运行以下命令:pg_basebackup -h master -D /var/lib/pgsql/9.3/data --username=replication --password

我错过了什么吗?是否有更好的方法使从属设备最新,而不必重新加载所有数据?

非常感谢您的帮助。

postgresql replication redhat
4个回答
24
投票

[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

注意: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.在步骤结束时带回奴隶

我在产品中这样做,它对我来说很完美。从机和主机同步,没有数据丢失。


0
投票
正如Ben Grimm在评论中建议的,这是确保将段设置为最大可能值以允许从站追赶的问题。

0
投票
您可以配置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');

© www.soinside.com 2019 - 2024. All rights reserved.