pgpool的健康检查和failover代码-skykiker-ChinaUnix博客

博客访问： 2951361
博文数量： 199
博客积分： 1400
博客等级：上尉
技术积分： 4126
用户组：普通用户
注册时间： 2008-07-06 19:06

个人简介

半个PostgreSQL DBA，热衷于数据库相关的技术。我的ppt分享https://pan.baidu.com/s/1eRQsdAa https://github.com/chenhuajun https://chenhuajun.github.io

文章分类

全部博文（199）

其他（1）
citus（10）
greenlpum（1）
安全（1）
Pacemaker（3）
MySQL（21）
Symfoware（2）

Native（1）
分布式（0）
C（1）
Solaris（1）
Linux（11）
C#（3）
故障案例（5）
NoSQL（4）
云计算（1）
Windows（3）
Database（13）
PostgreSQL（101）

安装配置（1）

HA（3）

doc（6）

Npgsql（1）

psqlODBC（2）
嵌入式开发（8）
Java开发（2）
生活随笔（3）
未分配的博文（4）

文章存档

2020年（5）

2019年（1）

2018年（12）

2017年（23）

2016年（43）

2015年（51）

2014年（27）

2013年（21）

2011年（1）

2010年（4）

2009年（5）

2008年（6）

我的朋友

相关博文

pgpool的健康检查和failover代码

分类： Mysql/postgreSQL

2016-11-16 00:15:24

健康检查
通过创建到后端的连接实施健康检查

main()
  PgpoolMain()
    processState = PERFORMING_HEALTH_CHECK;
      do_health_check()
        make_persistent_db_connection()
          discard_persistent_db_connection()

如果连接创建失败，会抛出异常，进而跳转到统一的异常处理点,如果超过重试次数，将后端降级,并最终调用pgpool.conf配置文件里设置的failover_command。

main()
  PgpoolMain()
    if(processState == PERFORMING_HEALTH_CHECK)
      process_backend_health_check_failure()
        degenerate_backend_set(&health_check_node_id,1)
          degenerate_backend_set_ex()
            register_node_operation_request(NODE_DOWN_REQUEST)
              failover()
                trigger_failover_command()

failover()的切换过程

再次确认后端状态，如无效更新后端的backend_status为CON_DOWN
获取第一个状态正常的后端作为new_master
kill所有子进程(这是基于pgpool做HA的一个很大的优势，可以可靠的切断所有来自客户端的连接，隔离故障节点)
对down掉的后端执行pgpool.conf配置文件里设置的failover_command
如果down掉的是primary，搜索新的primary，即第一个"SELECT pg_is_in_recovery()"返回不是t的后端。
重启所有子进程
发送restart通知给worker进程
通知PCP子进程failover/failback完成
发送restart通知给pcp进程

阅读(8709) | 评论(4) | 转发(0) |

上一篇：关于MySQL的分区索引

下一篇：基于PGPool的1主2从PostgreSQL流复制HA的搭建

给主人留下些什么吧！~~

kafkaaka2016-12-13 11:08:39

skykiker：确认一下是不是所有事务都是read committed，另外你是在什么情况下触发发这个问题的，怎么复现？

我晕，开发那边居然用的是可重复读。我是说咋会有这个错误。应该是并发更新导致的错误，现在就是看咋解决了！谢谢你

回复 | 举报

kafkaaka2016-12-13 09:31:03

skykiker：确认一下是不是所有事务都是read committed，另外你是在什么情况下触发发这个问题的，怎么复现？

我们的版本是9.3. After discussing this with the PostgreSQL developers, it appears to be a behavior change/regression introduced in 9.3, and fixed in upcoming 9.5. So 9.3 brings many performance improvements for concurrent transactions,
but actually makes this case worse.

The problem has to do with one transaction repeatedly acquiring the sam

回复 | 举报

skykiker2016-12-12 22:21:50

kafkaaka：hi，你好。想咨询个问题，PostgreSQL的事务隔离级别read committed是这个。但是日志里面报错：Postgresql could not serialize access due to concurrent update。我网上看了下，之前一直以为是在可串行化隔离级别下才会报这个错。现在能在日志里面找出来这一行，但是为什么会报这个错，如何解决呢。求大神指教一下，解决不了这个问题。。。

确认一下是不是所有事务都是read committed，另外你是在什么情况下触发发这个问题的，怎么复现？

回复 | 举报

kafkaaka2016-12-12 19:14:39

hi，你好。想咨询个问题，PostgreSQL的事务隔离级别read committed是这个。但是日志里面报错：Postgresql could not serialize access due to concurrent update。我网上看了下，之前一直以为是在可串行化隔离级别下才会报这个错。现在能在日志里面找出来这一行，但是为什么会报这个错，如何解决呢。求大神指教一下，解决不了这个问题。。。

回复 | 举报

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6