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

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 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数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
Kubernetes 负载均衡 监控
Istio 出错重试 重定向 熔断
Istio 出错重试 重定向 熔断
|
3月前
|
关系型数据库 PostgreSQL
【赵渝强老师】PostgreSQL的并行查询
PostgreSQL的并行查询功能通过多CPU提升查询速度,尤其适用于处理大量数据但返回少量结果的场景。它利用Leader进程、Gather节点和Worker线程协作完成查询任务,显著提高性能。本文详细解析其工作原理及适用场景,并通过实例展示开启与关闭并行查询的性能差异。
142 2
|
9月前
|
缓存 JSON 数据格式
harbor2.0安装
harbor2.0安装过程和私有镜像上传
894 2
harbor2.0安装
|
SQL 关系型数据库 MySQL
MySQL主从:延时从库恢复全解
MySQL主从:延时从库恢复全解
|
安全 关系型数据库 Linux
|
Kubernetes 中间件 调度
Rancher 系列文章 -K3S 集群升级
Rancher 系列文章 -K3S 集群升级
|
关系型数据库 数据安全/隐私保护 PostgreSQL
基于Docker快速搭建 PostgreSQL 高可用方案
基于Docker快速搭建 PostgreSQL 高可用方案
|
机器学习/深度学习 消息中间件 监控
阿里开源SpringBoot全栈小册!Github已标星百万
对于Spring Boot,我们都知道他的设计初衷是解决Spring各版本配置工作过于繁重的问题,简化初始搭建流程、降低开发难度而出现的。可以说用Spring Boot开发,我们在配置上是不用花费太多时间的。 我们常常看到这样一种现象:面对Spring繁重配置工作,要是一位初学者仅仅掌握了一点基础,可能花几天时间也配置不好环境。但是如果是用SpringBoot的话,完全就是“开箱即用”。Spring Boot有多香这一点想必大家也是有目共睹的,他对于Spring初学者来说是非常友好的,但是Spring Boot虽然易学但难“精”。即使在一线开发多年的老开发也不敢轻易说自己精通SpringBo
|
Python
ArcGIS模型构建器ModelBuilder的建模与使用
本文介绍在ArcMap软件中,基于模型构建器(ModelBuilder)完成模型建立与使用的具体方法~
443 1
ArcGIS模型构建器ModelBuilder的建模与使用
|
人工智能 Kubernetes Linux
将Kubernetes集群版本从1.18升级至1.24
本文记录了一次将Kubernetes集群从1.18.0版本升级到1.24.16版本的过程以及遇到的相关问题的解决。
2351 0