rsync增量重置备库

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介:



--在主从复制环境中,如果从库不小心打开了读写模式(相当单节点的一个数据),比如
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集群发生了主备切换后,这些只读节点能否与新的主节点保持
1817 0
|
2月前
|
SQL 存储 关系型数据库
Mysql主从同步 清理二进制日志的技巧
Mysql主从同步 清理二进制日志的技巧
30 1
|
5月前
|
存储 安全 容灾
同步与备份
【7月更文挑战第1天】同步与备份
170 70
|
SQL 关系型数据库 MySQL
Mysql使用binlog增量备份与恢复
Mysql使用binlog增量备份与恢复
348 0
举例:在从库上备份,到主库上恢复
在备库上备份,在主库上恢复 control file和recovery catalog的同步
|
关系型数据库 MySQL
mysqlbinlog同步数据
mysqlbinlog同步数据
123 0
|
关系型数据库 测试技术 数据库
PostgreSQL pg_rewind,时间线修复,脑裂修复,flashback - 从库开启读写后,回退为只读从库。异步主从发生角色切换后,主库rewind为新主库的从库
PostgreSQL pg_rewind,时间线修复,脑裂修复,flashback - 从库开启读写后,回退为只读从库。异步主从发生角色切换后,主库rewind为新主库的从库
2175 1
xtrabackup 增量,全备份,恢复备份
mysql5x 版本对应xrtabackup2.4
179 0
|
数据安全/隐私保护 算法 Shell