linux-HA 系统运用在pg数据库的一些想法
pg 数据库采用streaming 复制， 或者采用drdb 做文件系统的复制
如果采用drbd 则从库就不能提供只读访问了。
所以我们优先讨论streaming 复制的情况下。
1） pg的主从库的标记不足， 从库只有一个recover.conf 来标记从库，但是这个文件，放在主库也是可以的，不会引起什么问题
所以以此来评判主从库，存在不确定性。
2） 主从库的切换，HA 系统检测到主库损坏的时候，会发生资源切换，默认的行为是在从库上把slave 启动就完成了，这个时候，从库时么有切成主库的，提供还是只读访问。 针对这个问题，需要对pg的启动脚本做改造。
【1】 主从库部署不同的作业脚本，这个问题轻松解决，但是这样就要对linux-HA 的大规模部署带来一定挑战，需要人工干预的比较多。
【2】 单独开发开关脚本，在里面部署针对主从库的启动脚本。这样可以主从库部署同样的代码，由开关脚本来确定执行那个操作。
3) 这又回到了第一个问题，如何确定主从库的问题。
目前的想法，实现上也比较可行的：
4) 针对 主从库的识别问题，在主从库上分别设置标记文件： I-AM-MASTER , I-AM-SLAVE 这个标识文件可以在建库时，通过脚本自动化生成，或者手工建立。
5）避免主从库同事存在标记文件，数据库备份系统需要不备份这个标志文件。
6） 主库上的视图 pg_stat_replication 会反映主从库的一些信息，也可以作为两个文件同事存在的一些判断依据。
7） 接下来的事情是先按照这个思路，做一个demo 系统演示可行性。
如果采用drbd 则从库就不能提供只读访问了。
所以我们优先讨论streaming 复制的情况下。
1） pg的主从库的标记不足， 从库只有一个recover.conf 来标记从库，但是这个文件，放在主库也是可以的，不会引起什么问题
所以以此来评判主从库，存在不确定性。
2） 主从库的切换，HA 系统检测到主库损坏的时候，会发生资源切换，默认的行为是在从库上把slave 启动就完成了，这个时候，从库时么有切成主库的，提供还是只读访问。 针对这个问题，需要对pg的启动脚本做改造。
【1】 主从库部署不同的作业脚本，这个问题轻松解决，但是这样就要对linux-HA 的大规模部署带来一定挑战，需要人工干预的比较多。
【2】 单独开发开关脚本，在里面部署针对主从库的启动脚本。这样可以主从库部署同样的代码，由开关脚本来确定执行那个操作。
3) 这又回到了第一个问题，如何确定主从库的问题。
目前的想法，实现上也比较可行的：
4) 针对 主从库的识别问题，在主从库上分别设置标记文件： I-AM-MASTER , I-AM-SLAVE 这个标识文件可以在建库时，通过脚本自动化生成，或者手工建立。
5）避免主从库同事存在标记文件，数据库备份系统需要不备份这个标志文件。
6） 主库上的视图 pg_stat_replication 会反映主从库的一些信息，也可以作为两个文件同事存在的一些判断依据。
7） 接下来的事情是先按照这个思路，做一个demo 系统演示可行性。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/133735/viewspace-736787/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
PG 流复制的隐患以及处理措施
下一篇：
PG 数据库恢复实战
请登录后发表评论
登录
全部评论
