集群系统与事务处理需要注意的一点
2013-07-29 15:55
190 查看
因为Pgpool-II采用Master/Slave模式的时候,因偶然因素导致Pgpool-II与 SlaveDB之间的通信中断(L4SW主动切断)。
而此时某事务向Master数据库提交commit已经成功,在向SlaveDB提交因通信中断而失败。
这样,导致的结果是一方面向Master数据库提交成功,另一方面向前台程序返回出错信息的奇怪现象。
(由于客户的 fail_over_on_backend_error为假,故没有发生failover)
这是因为,首先,Pgpool-II中没有事务处理机制,或者说没有包含Transanction Manager,如果有,那么它可以利用数据库的两阶段提交能力,保证:要么两个数据库节点一起提交,要么一起回滚。当然,具体到Pgpool-II中,在Master/Slave模式也不允许这么作,但至少如果有Transaction Manager,如果出现通讯错,还是应该可以roll back的。
其次,展开了想一下,就算是有事务处理机制,就能保证数据库节点都提交或者都回滚了吗?
实际上,事务处理也就是利用所谓预提交方式,保证大家都预提交成功后,再一起真正提交或者一起真正回滚。
那如果"真"提交的时候出错了呢?还是说再搞三阶段提交、四阶段提交?
所以完美的事务处理是不存在的,应用和运维人员要考虑到这一点,准备好一旦数据在各节点间发生不一致后的对应方案。
而此时某事务向Master数据库提交commit已经成功,在向SlaveDB提交因通信中断而失败。
这样,导致的结果是一方面向Master数据库提交成功,另一方面向前台程序返回出错信息的奇怪现象。
(由于客户的 fail_over_on_backend_error为假,故没有发生failover)
这是因为,首先,Pgpool-II中没有事务处理机制,或者说没有包含Transanction Manager,如果有,那么它可以利用数据库的两阶段提交能力,保证:要么两个数据库节点一起提交,要么一起回滚。当然,具体到Pgpool-II中,在Master/Slave模式也不允许这么作,但至少如果有Transaction Manager,如果出现通讯错,还是应该可以roll back的。
其次,展开了想一下,就算是有事务处理机制,就能保证数据库节点都提交或者都回滚了吗?
实际上,事务处理也就是利用所谓预提交方式,保证大家都预提交成功后,再一起真正提交或者一起真正回滚。
那如果"真"提交的时候出错了呢?还是说再搞三阶段提交、四阶段提交?
所以完美的事务处理是不存在的,应用和运维人员要考虑到这一点,准备好一旦数据在各节点间发生不一致后的对应方案。
相关文章推荐
- 这是一个秒杀系统,即大量用户抢有限的商品,先到先得 用户并发访问流量非常大,需要分布式的机器集群处理请求 系统实现使用Java
- 好的事务处理系统,需要具备这些特征
- win7安装win8.1双系统需要注意的一点事
- django form系统一点需要注意的地方
- 分布式系统的事务处理
- 分布式系统的事务处理
- 开发长事务工具需要注意点
- 应用系统中的事务处理
- 一共81个,开源大数据处理工具汇总(下),包括日志收集系统/集群管理/RPC等
- 电路系统设计制作过程和需要注意的一些问题
- IO操作中关闭流的注意点(多个关闭时的异常需要单独处理)
- Hadoop 系统的存储引擎和在线事务处理
- 使用 FancyUpload需要注意的一点
- 深入解析:分布式系统的事务处理经典问题及模型
- DateTime处理的时候需要注意CultureInfo
- 邮件系统选择上,安全性上需要注意的一些要点
- 对数据库事务处理代码通常写法的一点改进
- mac系统开发java需要注意
- QT中使用控制台和Application需要注意的一点
- 分布式系统常见的事务处理机制