PostgreSQL 最佳实践 - 逻辑增量复制(MySQL <-> PgSQL <-> PgSQL)

alidecode是RDS PG提供的一个逻辑复制插件,使用它,可以将RDS PG通过逻辑复制的方式,把数据同步到线下的PostgreSQL。

同时还支持将MySQL的数据同步到PostgreSQL。

你还可用dbsync来实现平滑升级PostgreSQL的大版本,是不是很酷呢。

mysql2pgsql
https://help.aliyun.com/document_detail/35458.html

pgsql2pgsql
https://help.aliyun.com/document_detail/35459.html

源码
https://github.com/aliyun/rds_dbsync

下面是简单的使用方法。

准备工作,
提交工单,开放用户的replication角色。(目前RDS用户根账号已经默认带了replication权限,这个步骤可以忽略)

postgres=# alter role digoal replication;
ALTER ROLE

阿里云的RDS PG需要将主备的pg_hba.conf进行修正,增加replication的条目。
例子

$ vi $PGDATA/pg_hba.conf
host replication digoal 0.0.0.0/0 md5

阿里云的RDS PG需要调整主备的postgresql.conf,将wal_level改成logical。
并重启主备数据库,所以用户要开通此功能,需要重启实例哦

wal_level = logical

用户需要在RDS管控平台,配置白名单,允许alidecode客户端所在的主机连接RDS数据库。

下载alidecode客户端。
安装postgresql, mysql。(需要用到头文件)
如果你不需要将mysql的数据同步到PG,则不需要编译mysql的部分。
在Makefile和dbsync.h中注释掉mysql的部分即可。

编译前,你需要配置一下pgsync.cpp,这里需要配置三个连接串。
src对应RDS的连接串。
local对应的是一个中间库,它用来记录任务信息,记录全量同步时的增量数据(全量同步数据时,并行的接收xlog,接收的XLOG转义成SQL存在中间库)。
desc对应目标库,即数据要同步到这个库。

$ vi dbsync.cpp
        src =   (char *)"host=digoal_111.pg.rds.aliyuncs.com port=3433 dbname=db1 user=digoal password=digoal";
        local = (char *)"host=127.0.0.1 port=1925 dbname=db2 user=postgres password=postgres";
        desc = (char *)"host=127.0.0.1 port=1925 dbname=db1 user=postgres password=postgres";

编译
$ make

alidecode不负责DDL的同步,所以DDL需要用户自己操作
例子

/home/dege.zzz/pgsql9.5/bin/pg_dump -F p -s --no-privileges --no-tablespaces --no-owner -h digoal_111.pg.rds.aliyuncs.com -p 3433 -U digoal db1 | psql db1 -f -

同步数据,执行dbsync就可以了

./dbsync
full sync start 2016-05-26 15:35:42.336903, end 2016-05-26 15:35:42.699032 restart decoder sync
decoder sync start 2016-05-26 15:35:42.337482
decoder slot rds_logical_sync_slot exist
starting logical decoding sync thread
starting decoder apply thread
pg_recvlogical: starting log streaming at 0/0 (slot rds_logical_sync_slot)
pg_recvlogical: confirming recv up to 0/0, flush to 0/0 (slot rds_logical_sync_slot)

元数据记录在db2,如果失败要重新来过的话,建议清除它,同时清除目标库的已同步数据,然后重新调用dbsync。

db2=# \dt
             List of relations
 Schema |      Name      | Type  |  Owner
--------+----------------+-------+----------
 public | db_sync_status | table | postgres
 public | sync_sqls      | table | postgres
(2 rows)

db2=# drop table db_sync_status ;
DROP TABLE
db2=# drop table sync_sqls ;
DROP TABLE

压测rds

pgbench -M prepared -n -r -P 1 -c 80 -j 80 -T 100 -h digoal_111o.pg.rds.aliyuncs.com -p 3433 -U digoal db1

可以看到同步的过程

pg_recvlogical: confirming recv up to 1/4EE3F08, flush to 1/4EE3F08 (slot rds_logical_sync_slot)
pg_recvlogical: confirming recv up to 1/4F8BA20, flush to 1/4F8BA20 (slot rds_logical_sync_slot)
pg_recvlogical: confirming recv up to 1/5025228, flush to 1/5025228 (slot rds_logical_sync_slot)
pg_recvlogical: confirming recv up to 1/50C6E68, flush to 1/50C6E68 (slot rds_logical_sync_slot)
pg_recvlogical: confirming recv up to 1/51578A0, flush to 1/51578A0 (slot rds_logical_sync_slot)
pg_recvlogical: confirming recv up to 1/51E7CF8, flush to 1/51E7CF8 (slot rds_logical_sync_slot)

压测完后,查看数据是否一致

psql -h 127.0.0.1 db1
db1=# select sum(hashtext(t.*::text)) from pgbench_accounts t;
      sum
---------------
 -582104340143
(1 row)

psql -h digoal_111o.pg.rds.aliyuncs.com -p 3433 -U digoal db1
psql (9.6beta1, server 9.4.1)
Type "help" for help.

db1=> select sum(hashtext(t.*::text)) from pgbench_accounts t;
      sum
---------------
 -582104340143
(1 row)

db_sync工具下载地址
https://github.com/aliyun/rds_dbsync

时间: 2024-09-13 07:55:12

PostgreSQL 最佳实践 - 逻辑增量复制(MySQL <-> PgSQL <-> PgSQL)的相关文章

PostgreSQL 最佳实践 - 在线增量备份与任意时间点恢复

背景 冷备份, 以及逻辑备份都是某一个时间点的备份, 没有增量的概念. 如果数据库在运行过程中发生故障, 使用逻辑备份只能将数据库还原到备份时刻, 无法恢复到故障发生前的那个时刻. 又或者在使用过程中由于误操作修改或删除了重要数据, 需要还原到误操作前的那个时刻怎么办呢? 使用冷备份加上有效的归档文件可以实现任意时间点的恢复. 但是冷备份需要停库操作, 所以实用性不大. 本文要介绍的是在线的数据库文件备份, 弥补了冷备份的缺陷, 同时又支持基于时间点的恢复. 同时本文会介绍基于时间点(xid,

PostgreSQL 最佳实践 - 块级增量备份(ZFS篇)多zfs卷场景一致性备份

背景 当我们使用了多个ZFS卷或者文件系统时,如果一个实例的多个部分,如表空间,放在了不同的zfs上,再使用基于ZFS快照的备份时,可能出现多个文件系统不一致的情况. 例如控制文件是新的,但是数据是旧的. 保物理备份的一致性检查 基于文件的物理备份,为了保证备份的一致性,在备份开始时,需要做一个检查点,同时打开FULL PAGE WRTIE,同时还会生成backup_label文件记录备份开始时的WAL文件,检查点位置等信息. backup_label文件内容示例 START WAL LOCAT

贷款、天使投资(风控助手)业务数据库设计 - 阿里云RDS PostgreSQL, HybridDB for PostgreSQL最佳实践

标签 PostgreSQL , HybridDB for PostgreSQL , 小微贷款 , 金融风控 , 企业图谱 , 图式搜索 , 舆情分析 , 自动贷款 , 贷款审查 , 审查神器 背景 贷款是银行的主营业务之一,但是并不是只有银行能提供贷款,实际上资金雄厚的公司都有能力提供贷款(比如保险行业.资源垄断型企业等). 除了放贷,我们常说的天使投资.A轮B轮啥的,也是类似的场景,凭什么投你,背后如何决策也需要决策系统的支撑. 与贷款相反的是吸金类业务,比如我们现在发现越来越多的理财产品.股

云端流计算、在线业务、实时分析 闭环设计 - 阿里云RDS、HybridDB for PostgreSQL最佳实践

背景 水的流动汇成江河大海,孕育生命,形成大自然生态.数据流动,推进社会进步,拓展业务边界. <从人类河流文明 洞察 数据流动的重要性> 以某淘系业务案例展开,看看用户如何利用阿里云RDS PostgreSQL,HybridDB for PostgreSQL,海量对象存储OSS,打造一个从流计算到在线业务,再到数据分析和挖掘的业务,发挥数据的价值,拓展业务的边界. 业务简介 一个电商业务通常会涉及 商家.门店.物流.用户.支付渠道.贷款渠道.商品.平台.小二.广告商.厂家.分销商.店主.店员.

机票业务(单实例 2700万行/s return)数据库架构设计 - 阿里云RDS PostgreSQL最佳实践

背景 机票业务的某个模块,数据量10亿+,写.更新.删除量较低.根据KEY查询一些数据,每次查询返回1万条左右的记录. 就是这样简单的需求,业务方发现读成为了巨大的瓶颈,每次返回1万条,100个并发请求,每秒就是100万条(500MB左右),主要的瓶颈: 1.网络是个较大的开销. 2.不同KEY的数据可能是分散存放的,存在查询时的IO放大,可能有一定的性能影响. 3.每次请求的返回记录数较多,数据库search buffer调用可能开销会上升. 就这几个问题,我们来看看如何优化或解决业务方的问题

PostgreSQL 最佳实践 - 读写分离

背景 一直以来PostgreSQL数据库在scale up和scale out的方向都走得比较靠前,例如 单元化技术 oleg postgrespro的 PostgreSQL cluster,在分布式事务性能提升,选举算法方面的贡献非常大.https://github.com/postgrespro/postgres_cluster sim 他们的udr, bdr已经趋于成熟.https://2ndquadrant.com/en/resources/bdr/ 分片技术 10年前postgresq

(新零售)商户网格化运营 - 阿里云RDS PostgreSQL最佳实践

标签 PostgreSQL , PostGIS , 地理位置 , KNN , 近邻检索 , 网格检索 , polygon中心点 , 半径搜索 背景 伟大的马老师说: "纯电商时代很快会结束,未来的十年.二十年,没有电子商务这一说,只有新零售这一说,也就是说线上线下和物流必须结合在一起,才能诞生真正的新零售" 线上是指云平台,线下是指销售门店或生产商,新物流消灭库存,减少囤货量. 电子商务平台消失是指,现有的电商平台分散,每个人都有自己的电商平台,不再入驻天猫.京东.亚马逊大型电子商务平

音视图(泛内容)网站透视分析 DB设计 - 阿里云(RDS、HybridDB) for PostgreSQL最佳实践

标签 PostgreSQL , 用户透视 , 设备透视 , 圈人 , 标签 , 视频网站 , 优酷 , 土豆 , 喜马拉雅 背景 日常生活中,人们使用最多的除了社交类网站.购物网站,估计就是音频.视频.图文信息类内容网站了. 视频网站,已经渗透到各种终端,除了喜闻乐见的手机,还包括移动终端.电脑.盒子.电视.投影仪等.有设备属性.会员属性.渠道属性等. 内容运营是非常重要的环节,而透视则是运营的重要武器. 业务需求 1.生成设备.会员画像 ID.各个维度的标签.其中包括一些多值列标签(例如最近7

海量实时计算+OLTP+OLAP DB设计 - 阿里云(RDS、HybridDB) for PostgreSQL最佳实践 - 泛电网系统应用

标签 PostgreSQL , 国家电网 , 电表 , 余额 , 流式计算 , 状态监测 , 上下文相关 背景 电网系统是一个关系民生,又非常典型的传统系统,虽然传统,量可不小.在互联网化(物联网化)的今天,有很多值得借鉴和思考的点供给其他相关系统参考. 每个省份大概有亿级户电表,最大的地市可能有千万户级别. 以往我们电费是怎么交的呢?我们小区是两个月交一次,也就是说先消费,再付款的方式.这么说起来电网真的是很仁义啊,现在哪有这么多先消费再付款的呀.移动话费.家庭宽带.天然气等等,都是充值后使用