FATAL,XX000,"highest timeline 14 of the primary is behind recovery timeline 15" rsync 增量重置备库

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: --在主从复制环境中,如果从库不小心打开了读写模式(相当单节点的一个数据),比如touch /usr/local/postgresql/9.
--在主从复制环境中,如果从库不小心打开了读写模式(相当单节点的一个数据),比如
touch /usr/local/postgresql/9.3.4/5434/pgsql.recovery.trigger
--此时从节点已经于主机点脱离,此时再把这个节点改为从节点时,由于从的timeline高于主,故该节点不能再变成从节点了
[postgres@rudy_01 5434]$ ls | grep recovery
recovery.done
[postgres@rudy_01 5434]$ pg_ctl stop -m fast -D /usr/local/postgresql/9.3.4/5434
[postgres@rudy_01 5434]$ mv recovery.done recovery.conf
[postgres@rudy_01 5434]$ pg_ctl start -m fast -D /usr/local/postgresql/9.3.4/5434 -l serverlog
--从log日志中可以看到如下错误
FATAL,XX000,"highest timeline 14 of the primary is behind recovery timeline 15"


--如果要想把该节点变成从节点需要同同步主机点的数据到从节点
--本次操作以rsync方式进行,注意,如果主进行了大量的变更,rsync要占用大量的网络流量与io,请慎重

--在之前的从节点停止数据库实例
pg_ctl stop -m fast -D /usr/local/postgresql/9.3.4/5434

--在主机点执行rsync_standby.sh脚本
#/bin/sh -x
PRIMARY_PORT=5433
STANDBY_PORT=5434
SOURCE_CLUSTER=/usr/local/postgresql/9.3.4/5433
DEST_CLUSTER=/usr/local/postgresql/9.3.4/5434
PGCTL=/usr/local/postgresql/9.3.4/bin/pg_ctl
recovery_node_host_name=rudy_01
primary_host_name=rudy
psql -p $PRIMARY_PORT -c "SELECT pg_start_backup('file_based_log_shipping', true)" postgres
/usr/bin/rsync -C -a -c --delete --exclude postmaster.pid \
--exclude postgresql.trigger.* --exclude postmaster.opts --exclude pg_log \
--exclude recovery.conf --exclude recovery.done \
--exclude pg_xlog \
$SOURCE_CLUSTER/ $recovery_node_host_name:$DEST_CLUSTER/
ssh -T $recovery_node_host_name /bin/rm -rf $DEST_CLUSTER/pg_xlog
ssh -T $recovery_node_host_name /bin/mkdir $DEST_CLUSTER/pg_xlog
ssh -T $recovery_node_host_name /bin/chmod 700 $DEST_CLUSTER/pg_xlog
ssh -T $recovery_node_host_name /bin/rm -rf $DEST_CLUSTER/recovery.done
ssh -T $recovery_node_host_name "/bin/cat > $DEST_CLUSTER/recovery.conf <<EOF
standby_mode          = on
primary_conninfo      = 'port=$PRIMARY_PORT user=repuser host=$primary_host_name'
trigger_file = '$DEST_CLUSTER/pgsql.recovery.trigger'
recovery_target_timeline = 'latest'
EOF"
ssh -T $recovery_node_host_name "sed -i 's/$PRIMARY_PORT/$STANDBY_PORT/g' $DEST_CLUSTER/postgresql.conf"
psql -p $PRIMARY_PORT -c "SELECT pg_stop_backup()" postgres
ssh -T $recovery_node_host_name $PGCTL -w -D $DEST_CLUSTER start 2>/dev/null 1>/dev/null < /dev/null &


相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
弹性计算 网络协议 容灾
PostgreSQL 时间点恢复(PITR)在异步流复制主从模式下,如何避免主备切换后PITR恢复(备库、容灾节点、只读节点)走错时间线(timeline , history , partial , restore_command , recovery.conf)
标签 PostgreSQL , 恢复 , 时间点恢复 , PITR , restore_command , recovery.conf , partial , history , 任意时间点恢复 , timeline , 时间线 背景 政治正确非常重要,对于数据库来说亦如此,一个基于流复制的HA架构的集群,如果还有一堆只读节点,当HA集群发生了主备切换后,这些只读节点能否与新的主节点保持
1807 0
|
11月前
|
关系型数据库 数据库
Harbor断电重启postgres报错 could not locate a valid checkpoint record
Harbor断电重启postgres报错 could not locate a valid checkpoint record
421 0
relay_log_recovery和slave从库crash recovery的关系
在从库中将relay_log_recovery不设置或者设置为off,如果当从库意外宕机后,同时从库的relay log也一起损坏了,从库会丢失那些没有应用的日志,主从会不一致。
174 0
|
弹性计算 容灾 关系型数据库
PostgreSQL PITR 任意时间点恢复过程中如何手工得到recovery需要的下一个WAL文件名 - 默认情况下restore_command自动获取
标签 PostgreSQL , recovery , recovery.conf , restore_command , timeline , 时间线 , next wal , PITR , 时间点恢复 背景 PostgreSQL数据库支持PITR时间点恢复。默认情况下,只需要配置目标是时间点,resotre_command即可,PG会自动调用resotre_command去找需要的WA
1499 0
|
SQL 弹性计算 关系型数据库
为什么pg_basebackup或pg_start_backup好像hang住确没有开始拷贝文件 - checkpoint 的几种调度(checkpoint_completion_target)
标签 PostgreSQL , checkpoint , 调度 , lazy , immediate , pg_start_backup , pg_basebackup 背景 PostgreSQL支持在线全量备份与增量归档备份。在线全量备份实际上就是拷贝文件,增量备份则分为两种,一种是基于BLOCK lsn变化的BLOCK即增量备份,另一种是基于WAL的持续归档文件备份。 全量备份通常
1591 0