由于master宕机等导致resource调用出现异常,直接将该resource返回到pool以便其他代码使用会导致得到不可预期的结果,导致返回数据混乱。

实现一:
public String get(final String key) {         
     Jedis resource = null;         
     try {                   
        resource = pool.getResource();                   
         return resource.get(key);       
    } finally {                   
        pool.returnResourceObject(resource);        
    }
}

实现二:
public String get(final String key) {         
     Jedis resource = null;         
     try {                   
           resource = pool.getResource();                   
           return resource.get(key);         
     } finally {                   
           resource.close();         
     }
 }

哨兵的监控:
 手动关闭 master: [email protected]:6379
29350:X 06 Aug 09:31:36.184 # +sdown master mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.251 # +odown master mymaster 10.91.230.120 6379 #quorum 4/2
29350:X 06 Aug 09:31:36.251 # +new-epoch 71
哨兵发现master宕机,他们会选举一个slave成为master
29350:X 06 Aug 09:31:36.251 # +try-failover master mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.253 # +vote-for-leader 4619691f4385e4098ed8eba52dd254827d33e44b 71
29350:X 06 Aug 09:31:36.258 # 10.91.230.120:26380 voted for 4619691f4385e4098ed8eba52dd254827d33e44b 71
29350:X 06 Aug 09:31:36.259 # 10.91.230.119:26380 voted for 4619691f4385e4098ed8eba52dd254827d33e44b 71
29350:X 06 Aug 09:31:36.260 # 10.91.230.120:26379 voted for 4619691f4385e4098ed8eba52dd254827d33e44b 71
29350:X 06 Aug 09:31:36.354 # +elected-leader master mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.354 # +failover-state-select-slave master mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.444 # +selected-slave slave 10.91.230.119:6379 10.91.230.119 6379 @ mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.444 * +failover-state-send-slaveof-noone slave 10.91.230.119:6379 10.91.230.119 6379 @ mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.500 * +failover-state-wait-promotion slave 10.91.230.119:6379 10.91.230.119 6379 @ mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.979 # +promoted-slave slave 10.91.230.119:6379 10.91.230.119 6379 @ mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:36.980 # +failover-state-reconf-slaves master mymaster 10.91.230.120 6379
29350:X 06 Aug 09:31:37.031 # +failover-end master mymaster 10.91.230.120 6379
// 哨兵切换被选中的slave成为master
29350:X 06 Aug 09:31:37.031 # +switch-master mymaster 10.91.230.120 6379 10.91.230.119 6379
// 哨兵切换旧master为slave
29350:X 06 Aug 09:31:37.031 * +slave slave 10.91.230.120:6379 10.91.230.120 6379 @ mymaster 10.91.230.119 6379
// 手动开启旧的master,哨兵切换旧master为slave
29350:X 06 Aug 09:31:47.975 * +convert-to-slave slave 10.91.230.120:6379 10.91.230.120 6379 @ mymaster 10.91.230.119 6379

症状:
见实现一,master宕机,哨兵选举一个slave成为master,则调用某些resource的代码会报TIMEOUT的异常(此类resource已经由于master宕机等异常而broken,由于resource对网络socket进行了封装和buffer,异常的发生毁导致下一次返回出来的数据不可预期,需要主动关闭它,而不是官方示例代码那样直接在final块里面将它返回到pool中),在哨兵切换选中的slave成为新的master之后,调用此resource的代码就会获得不可预期的返回。

解决方案:
见实现二,在异常发生的时候,主动关闭该resource,则返回数据混乱的问题不会发生。

时间: 2024-10-12 16:27:26

由于master宕机等导致resource调用出现异常,直接将该resource返回到pool以便其他代码使用会导致得到不可预期的结果,导致返回数据混乱。的相关文章

MySQL master 宕机导致slave数据库比master多的case

先说环境吧: Server version:         5.6.16-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial) mysql> show variables like '%innodb_flush_log_at_trx_commit%'; +--------------------------------+-------+ | Variable_name

linux 双Redis + keepalived 主从复制+宕机自主切换

主要核心思想,如果master 和 salve 全部存活的情况,VIP就漂移到 master.读写都从master操作,如果master宕机,VIP就会漂移到salve,并将之前的salve切换为master,当宕机的master可以继续服务的时候,首先会从salve同步数据,然后VIP漂移到master服务器上面,持续提供服务. 环境准备: master:ip 192.168.28.139:redis 19020:redis 19021:keepalived slave :ip 192.168

Mysql DBA 高级运维学习笔记-一主多从宕机从库切换主继续和从库同步过程

1.主库master 宕机 登录从库show processlist\G 看两个线程的更新状态 mysql> show processlist\G *************************** 1. row *************************** Id: 1 User: system user Host: db: NULL Command: Connect Time: 22997 State: Waiting for master to send event Info:

Redis(六)——高可用之哨兵sentinel配置与启动及主从服务宕机与恢复

.主从复制高可用 #主从复制存在的问题: 1 主从复制,主节点发生故障,需要做故障转移,可以手动转移:让其中一个slave变成master 2 主从复制,只能主写数据,所以写能力和存储能力有限 哨兵是对Redis的系统的运行情况的监控,它是一个独立进程,它会独立运行,功能有二个: 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器. 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机.

clickhouse高可用及节点宕机数据一致性方案

1. 集群节点及服务分配 说明: 1.1. 在每个节点上启动两个clickhouse服务(后面会详细介绍如何操作这一步),一个数据分片,一个数据备份,为了确保宕机数据一致性,数据分片和数据备份不能同一节点,比如gawh201上的shard不能备份在gawh201的replica,如果这样做,当gawh201宕机了,该节点shard的数据是找不到的. 1.2. 基于a所以shard和replica必须错开,但不是随意错开就可以了.按照上图给的规律错开(后面会详细介绍超大节点的集群的shard和re

一次慢日志撑爆磁盘导致的业务主库宕机引发的思考

在MySQL的日常维护中,我们总会遇到这样或那样的问题,对于那些经常发生且有处理经验的事故,不论是新手还是老司机都能在故障规定的容错时间内解决.而对于那些不常见.比较棘手的问题,新手上路可能就显得举足无措了,这个时候新手和老司机的差距就体现出来了.从知识储备还是工作经验,可能老司机比新手强一点,但如果一个新司机没有日志排错的意识,不具备日志排错的经验,那怎么能学会弯道超车.漂移的快感.我们知道数据库中有很多重要的日志,如错误日志error log.慢日志slow log.二进制日志binary

数据库修改字段导致宕机

170614 23:28:56 [ERROR] Slave SQL: Error 'Got error 64 'Temp file write failure' from InnoDB' on query. Default database: 'loandb'. Query: 'ALTER TABLE 'trd_loanapply DROP COLUMN LAP_SIGNRATE , Internal MariaDB error code: 1296 170614 23:28:56 [Warni

那些年我们踩到过的坑(二):3.1 版 MultiThreadedHttpConnectionManager 未releaseConnection导致应用服务器宕机

昨天短信服务又宕机了,jstack打出线程信息发现 所有线程池的线程都在wait,栈信息如下: at java.lang.Object.wait(Native Method) - waiting on [0x000000070754fb60] (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool) at org.apache.commons.httpclient.MultiThread

weblogic out of space in CodeCache for adapters导致宕机

weblogic会莫名的宕机,宕机日志跟以往的不同: Caused By: java.lang.VirtualMachineError: out of space in CodeCache for adapters at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at net.sf.jasperreports.engine.fill.JREvaluato