rsync增量重置备库



--在主从复制环境中,如果从库不小心打开了读写模式(相当单节点的一个数据),比如
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 &
时间: 2024-11-03 22:04:04

rsync增量重置备库的相关文章

Linux VPS自动备份:脚本上传FTP及RSYNC增量备份

  ☆☆☆一.每日自动备份网站数据及数据库上传FTP☆☆☆   这个方式,主要是一个脚本(包含压缩网站数据及数据库,上传),然后用cron命令每天在指定时间段运行,下面请看脚本代码(脚本内信息需自行设定)    代码如下 复制代码 #!/bin/bash #以下信息请自行修改 MYSQL_USER=root                    #mysql用户名 MYSQL_PASS=123456                      #mysql密码 MAIL_TO=admin@zrbl

rsync增量传输大文件优化技巧

RSync服务器配置 确保安装了rsync 配置/etc/rsyncd.conf,一般情况下安装了rsync不会自动创建rsyncd.conf,配置如下  代码如下 复制代码 # Rsync configuration file secrets file = /etc/rsyncd.secrets #认证用户名和密码文件的名称和位置 motd file = /etc/rsyncd.motd #欢迎文件,可自己编辑 read>list = yes uid = root gid = root use

DG2.1——物理备库搭建

原文转自:http://blog.csdn.net/tianlesoftware/article/details/5547565 1.linux平台 Data Guard 环境: 操作系统: redhat 5.5 Primary数据库: IP地址:211.87.147.69 数据库SID:mynew1 DB_UNIQUE_NAME:mynew1_pd   Standby数据库: IP地址:211.87.147.68 数据库SID:mynew1 DB_UNIQUE_NAME:mynew1_st  

PostgreSQL on ECS SLA 流复制备库+秒级快照+PITR+自动清理

标签 PostgreSQL , ECS , 阿里云 , 部署 , 物理镜像 , 流复制 , 快照备份 , 备份验证 , 自动清理 背景 介绍在阿里云ECS环境中,实现一个非常简单,但是可用性和可靠性满足一般企业要求的PostgreSQL环境. 包括: 1.自动启动数据库 2.包括一个物理流复制备库 3.包括自动的秒级快照备份 4.包括自动备份集有效性验证 5.包括自动清理N天以前的备份集.归档文件 6.监控请自建 部署环境介绍 1.ECS 111.111.111.199 (主) 111.111.

Rsync同步错误

-------------------------------------------------------------- Beginning sync:2012/06/06 15:50 [to - 61.147.88.115 ] Beginning sync:2012/06/06 15:50 [to - 222.186.32.15 ] Beginning sync:2012/06/06 15:50 [to - 222.186.38.5 ] rsync: failed to connect t

Dart基础-泛型和库

泛型 如果你看过API文档的基本类型数组和列表,你会发现实际上所有都是泛型,使用泛型可以提高代码的可读性 var names = new List<String>(); names.addAll(['Seth', 'Kathy', 'Lars']); //检查模式编译失败,生产模式编译成功 names.add(42); 使用泛型的另一个原因是减少代码重复,泛型可以创建多类型共享的接口,同时还能在检查模式早期预警,假如您创建一个接口缓存对象 abstract class ObjectCache

【DATAGUARD】 基于同一个主机建立物理备库和逻辑备库 (三)

[DATAGUARD] 基于同一个主机建立物理备库和逻辑备库 (三) blog文档结构图:         需求: 在同一台机器配置10g单实例+物理dg+逻辑dg,即一个主库上挂2个备库,一个物理备库,一个逻辑备库,总体思路为:先搭建2台物理dg,然后将其中的一台转换为逻辑dg   之前发布过一步一步搭建 oracle 11gR2 rac + dg,这里的dg为物理dg,但是实际自己使用过程中发现需要开3个虚拟机,机器特卡,所以决定在同一台机器上再搭建一台物理和逻辑dg. 一步一步搭建 ora

【DATAGUARD】 基于同一个主机建立物理备库和逻辑备库(一)

[DATAGUARD] 基于同一个主机建立物理备库和逻辑备库(一)      之前发布过一步一步搭建 oracle 11gR2 rac + dg,这里的dg为物理dg,但是实际自己使用过程中发现需要开3个虚拟机,机器特卡,所以决定在同一台机器上再搭建一台物理和逻辑dg. 一步一步搭建 oracle 11gR2 rac + dg 之前传(一) http://blog.itpub.net/26736162/viewspace-1290405/  一步一步搭建oracle 11gR2 rac+dg之环

11g备库无法开启ADG的原因分析

今天碰到一个有些奇怪的问题,但是奇怪的现象背后都是有本质的因果. 下午在做一个环境的检查时,发现备库是在mount阶段,这可是一个11gR2的库,没有ADG实在是太浪费了,对于这种情况感觉太不应该了. 所以尝试启动至open阶段,发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊. 使用dg broker设置为READ-ONLY,备库的数据库日志如下:      Standby Database:           stestdb3, Enable