• MySQL--MHA与GTID


    ##==========================================##

    MySQL 5.6版本引入GTID来解决主从切换时BINLOG位置点难定位的问题,MHA从0.56版本开始支持基于GTID的复制,在发生故障切换时判断群集是否能采用基于GTID的方式进行切换

    ##==========================================##
    基于GTID进行故障切换的条件:
    1、所有节点开启GTID模式,设置gtid_mode=1
    2、所有节点上Executed_Gtid_Set不为空
    3、至少一个节点使用Auto_Position=1

    ##==========================================##
    基于GTID进行故障切换:
    1、如果候选Master节点不拥有最新的Relay log,那么将候选Master连接到拥有最新Relay log的Salve上进行日志补偿
    2、如果群集中使用Binlog Server,则尝试从Binlog Server上拉取缺失的Binlog并应用到候选Master上
    3、候选Matser拥有最新数据,将其升级为新Master,将其他slave连接到新Master上进行数据同步,可以给masterha_master_switch传入–wait_until_gtid_in_sync=1参数使其不等其它Slave完成数据同步,以加快切换速度。

    ##==========================================##
    基于GTID模式进行故障切换时,无论原Master节点OS是否正常,都不会尝试从原Master节点读取BINLOG进行日志补偿。
    基于GTID模式的MHA支持在复制拓扑中使用BINLOG Server来进行日志补偿,而非GTID模式的MHA会忽略BINLOG Server。
    建议在基于GTID模式的群集中,不使用MHA进行"手动主从切换",该操作可能会导致原主库上部分BINLOG丢失。

    ##==========================================##
    在非GTID模式下,会先进行Phase 3.1阶段,从拥有最新BINLOG的从库上获取差异日志,再进行Phase 3.2阶段,尝试从原Master服务器上获取最新BINLOG。
     

    使用非GTID模式切换的日志

    View Code

    ##==========================================##
    在基于GTID模式下,不会进行Phase 3.2阶段,即尝试从原Master服务器中获取最新BINLOG。

    使用GTID模式切换的日志:

    Sun Jul  8 23:35:21 2018 - [info] MHA::MasterMonitor version 0.56.
    Sun Jul  8 23:35:21 2018 - [info] GTID failover mode = 1
    Sun Jul  8 23:35:21 2018 - [info] Dead Servers:
    Sun Jul  8 23:35:21 2018 - [info] Alive Servers:
    Sun Jul  8 23:35:21 2018 - [info]   10.0.203.104(10.0.203.104:3358)
    Sun Jul  8 23:35:21 2018 - [info]   10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:35:21 2018 - [info]   10.0.203.117(10.0.203.117:3358)
    Sun Jul  8 23:35:21 2018 - [info] Alive Slaves:
    Sun Jul  8 23:35:21 2018 - [info]   10.0.203.104(10.0.203.104:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:35:21 2018 - [info]     GTID ON
    Sun Jul  8 23:35:21 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:35:21 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
    Sun Jul  8 23:35:21 2018 - [info]   10.0.203.117(10.0.203.117:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:35:21 2018 - [info]     GTID ON
    Sun Jul  8 23:35:21 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:35:21 2018 - [info] Current Alive Master: 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:35:21 2018 - [info] Checking slave configurations..
    Sun Jul  8 23:35:21 2018 - [info]  read_only=1 is not set on slave 10.0.203.104(10.0.203.104:3358).
    Sun Jul  8 23:35:21 2018 - [info]  read_only=1 is not set on slave 10.0.203.117(10.0.203.117:3358).
    Sun Jul  8 23:35:21 2018 - [info] Checking replication filtering settings..
    Sun Jul  8 23:35:21 2018 - [info]  binlog_do_db= , binlog_ignore_db= 
    Sun Jul  8 23:35:21 2018 - [info]  Replication filtering check ok.
    Sun Jul  8 23:35:21 2018 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
    Sun Jul  8 23:35:21 2018 - [info] Checking SSH publickey authentication settings on the current master..
    Sun Jul  8 23:35:22 2018 - [info] HealthCheck: SSH to 10.0.203.109 is reachable.
    Sun Jul  8 23:35:22 2018 - [info] 
    10.0.203.109(10.0.203.109:3358) (current master)
     +--10.0.203.104(10.0.203.104:3358)
     +--10.0.203.117(10.0.203.117:3358)
    
    Sun Jul  8 23:35:22 2018 - [warning] master_ip_failover_script is not defined.
    Sun Jul  8 23:35:22 2018 - [warning] shutdown_script is not defined.
    Sun Jul  8 23:35:22 2018 - [info] Set master ping interval 1 seconds.
    Sun Jul  8 23:35:22 2018 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
    Sun Jul  8 23:35:22 2018 - [info] Starting ping health check on 10.0.203.109(10.0.203.109:3358)..
    Sun Jul  8 23:35:22 2018 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..
    Sun Jul  8 23:35:58 2018 - [warning] Got error on MySQL select ping: 2006 (MySQL server has gone away)
    Sun Jul  8 23:35:58 2018 - [info] Executing SSH check script: exit 0
    Sun Jul  8 23:35:58 2018 - [info] HealthCheck: SSH to 10.0.203.109 is reachable.
    Sun Jul  8 23:35:59 2018 - [warning] Got error on MySQL connect: 2013 (Lost connection to MySQL server at 'reading initial communication packet', system error: 111)
    Sun Jul  8 23:35:59 2018 - [warning] Connection failed 2 time(s)..
    Sun Jul  8 23:36:00 2018 - [warning] Got error on MySQL connect: 2013 (Lost connection to MySQL server at 'reading initial communication packet', system error: 111)
    Sun Jul  8 23:36:00 2018 - [warning] Connection failed 3 time(s)..
    Sun Jul  8 23:36:01 2018 - [warning] Got error on MySQL connect: 2013 (Lost connection to MySQL server at 'reading initial communication packet', system error: 111)
    Sun Jul  8 23:36:01 2018 - [warning] Connection failed 4 time(s)..
    Sun Jul  8 23:36:01 2018 - [warning] Master is not reachable from health checker!
    Sun Jul  8 23:36:01 2018 - [warning] Master 10.0.203.109(10.0.203.109:3358) is not reachable!
    Sun Jul  8 23:36:01 2018 - [warning] SSH is reachable.
    Sun Jul  8 23:36:01 2018 - [info] Connecting to a master server failed. Reading configuration file /etc/masterha_default.cnf and /etc/masterha/app1.cnf again, and trying to connect to all servers to check server status..
    Sun Jul  8 23:36:01 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
    Sun Jul  8 23:36:01 2018 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
    Sun Jul  8 23:36:01 2018 - [info] Reading server configuration from /etc/masterha/app1.cnf..
    Sun Jul  8 23:36:01 2018 - [info] GTID failover mode = 1
    Sun Jul  8 23:36:01 2018 - [info] Dead Servers:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info] Alive Servers:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.117(10.0.203.117:3358)
    Sun Jul  8 23:36:01 2018 - [info] Alive Slaves:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.117(10.0.203.117:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info] Checking slave configurations..
    Sun Jul  8 23:36:01 2018 - [info]  read_only=1 is not set on slave 10.0.203.104(10.0.203.104:3358).
    Sun Jul  8 23:36:01 2018 - [info]  read_only=1 is not set on slave 10.0.203.117(10.0.203.117:3358).
    Sun Jul  8 23:36:01 2018 - [info] Checking replication filtering settings..
    Sun Jul  8 23:36:01 2018 - [info]  Replication filtering check ok.
    Sun Jul  8 23:36:01 2018 - [info] Master is down!
    Sun Jul  8 23:36:01 2018 - [info] Terminating monitoring script.
    Sun Jul  8 23:36:01 2018 - [info] Got exit code 20 (Master dead).
    Sun Jul  8 23:36:01 2018 - [info] MHA::MasterFailover version 0.56.
    Sun Jul  8 23:36:01 2018 - [info] Starting master failover.
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 1: Configuration Check Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] GTID failover mode = 1
    Sun Jul  8 23:36:01 2018 - [info] Dead Servers:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info] Checking master reachability via MySQL(double check)...
    Sun Jul  8 23:36:01 2018 - [info]  ok.
    Sun Jul  8 23:36:01 2018 - [info] Alive Servers:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.117(10.0.203.117:3358)
    Sun Jul  8 23:36:01 2018 - [info] Alive Slaves:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.117(10.0.203.117:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info] Starting GTID based failover.
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] ** Phase 1: Configuration Check Phase completed.
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 2: Dead Master Shutdown Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] Forcing shutdown so that applications never connect to the current master..
    Sun Jul  8 23:36:01 2018 - [warning] master_ip_failover_script is not set. Skipping invalidating dead master IP address.
    Sun Jul  8 23:36:01 2018 - [warning] shutdown_script is not set. Skipping explicit shutting down of the dead master.
    Sun Jul  8 23:36:01 2018 - [info] * Phase 2: Dead Master Shutdown Phase completed.
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 3: Master Recovery Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 3.1: Getting Latest Slaves Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] The latest binary log file/position on all slaves is mysql-bin.000008:6689
    Sun Jul  8 23:36:01 2018 - [info] Retrieved Gtid Set: 541e0f07-8047-11e8-8434-0800270b00d2:49-69
    Sun Jul  8 23:36:01 2018 - [info] Latest slaves (Slaves that received relay log files to the latest):
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.117(10.0.203.117:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info] The oldest binary log file/position on all slaves is mysql-bin.000008:6689
    Sun Jul  8 23:36:01 2018 - [info] Retrieved Gtid Set: 541e0f07-8047-11e8-8434-0800270b00d2:49-69
    Sun Jul  8 23:36:01 2018 - [info] Oldest slaves:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.117(10.0.203.117:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 3.3: Determining New Master Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] Searching new master from slaves..
    Sun Jul  8 23:36:01 2018 - [info]  Candidate masters from the configuration file:
    Sun Jul  8 23:36:01 2018 - [info]   10.0.203.104(10.0.203.104:3358)  Version=5.7.19-log (oldest major version between slaves) log-bin:enabled
    Sun Jul  8 23:36:01 2018 - [info]     GTID ON
    Sun Jul  8 23:36:01 2018 - [info]     Replicating from 10.0.203.109(10.0.203.109:3358)
    Sun Jul  8 23:36:01 2018 - [info]     Primary candidate for the new Master (candidate_master is set)
    Sun Jul  8 23:36:01 2018 - [info]  Non-candidate masters:
    Sun Jul  8 23:36:01 2018 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
    Sun Jul  8 23:36:01 2018 - [info] New master is 10.0.203.104(10.0.203.104:3358)
    Sun Jul  8 23:36:01 2018 - [info] Starting master failover..
    Sun Jul  8 23:36:01 2018 - [info] 
    From:
    10.0.203.109(10.0.203.109:3358) (current master)
     +--10.0.203.104(10.0.203.104:3358)
     +--10.0.203.117(10.0.203.117:3358)
    
    To:
    10.0.203.104(10.0.203.104:3358) (new master)
     +--10.0.203.117(10.0.203.117:3358)
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 3.3: New Master Recovery Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info]  Waiting all logs to be applied.. 
    Sun Jul  8 23:36:01 2018 - [info]   done.
    Sun Jul  8 23:36:01 2018 - [info] Getting new master's binlog name and position..
    Sun Jul  8 23:36:01 2018 - [info]  mysql-bin.000006:77499
    Sun Jul  8 23:36:01 2018 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.203.104', MASTER_PORT=3358, MASTER_AUTO_POSITION=1, MASTER_USER='replicater', MASTER_PASSWORD='xxx';
    Sun Jul  8 23:36:01 2018 - [info] Master Recovery succeeded. File:Pos:Exec_Gtid_Set: mysql-bin.000006, 77499, 41d8a420-8047-11e8-8580-080027e837eb:1-92,
    541e0f07-8047-11e8-8434-0800270b00d2:1-69
    Sun Jul  8 23:36:01 2018 - [warning] master_ip_failover_script is not set. Skipping taking over new master IP address.
    Sun Jul  8 23:36:01 2018 - [info] ** Finished master recovery successfully.
    Sun Jul  8 23:36:01 2018 - [info] * Phase 3: Master Recovery Phase completed.
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 4: Slaves Recovery Phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 4.1: Starting Slaves in parallel..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] -- Slave recovery on host 10.0.203.117(10.0.203.117:3358) started, pid: 5680. Check tmp log /var/log/masterha/app1/10.0.203.117_3358_20180708233601.log if it takes time..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] Log messages from 10.0.203.117 ...
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info]  Resetting slave 10.0.203.117(10.0.203.117:3358) and starting replication from the new master 10.0.203.104(10.0.203.104:3358)..
    Sun Jul  8 23:36:01 2018 - [info]  Executed CHANGE MASTER.
    Sun Jul  8 23:36:01 2018 - [info]  Slave started.
    Sun Jul  8 23:36:01 2018 - [info]  gtid_wait(41d8a420-8047-11e8-8580-080027e837eb:1-92,
    541e0f07-8047-11e8-8434-0800270b00d2:1-69) completed on 10.0.203.117(10.0.203.117:3358). Executed 0 events.
    Sun Jul  8 23:36:01 2018 - [info] End of log messages from 10.0.203.117.
    Sun Jul  8 23:36:01 2018 - [info] -- Slave on host 10.0.203.117(10.0.203.117:3358) started.
    Sun Jul  8 23:36:01 2018 - [info] All new slave servers recovered successfully.
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] * Phase 5: New master cleanup phase..
    Sun Jul  8 23:36:01 2018 - [info] 
    Sun Jul  8 23:36:01 2018 - [info] Resetting slave info on the new master..
    Sun Jul  8 23:36:01 2018 - [info]  10.0.203.104: Resetting slave info succeeded.
    Sun Jul  8 23:36:01 2018 - [info] Master failover to 10.0.203.104(10.0.203.104:3358) completed successfully.
    Sun Jul  8 23:36:01 2018 - [info] 
    
    ----- Failover Report -----
    
    app1: MySQL Master failover 10.0.203.109(10.0.203.109:3358) to 10.0.203.104(10.0.203.104:3358) succeeded
    
    Master 10.0.203.109(10.0.203.109:3358) is down!
    
    Check MHA Manager logs at localhost.localdomain:/var/log/masterha/app1/manager.log for details.
    
    Started automated(non-interactive) failover.
    Selected 10.0.203.104(10.0.203.104:3358) as a new master.
    10.0.203.104(10.0.203.104:3358): OK: Applying all logs succeeded.
    10.0.203.117(10.0.203.117:3358): OK: Slave started, replicating from 10.0.203.104(10.0.203.104:3358)
    10.0.203.104(10.0.203.104:3358): Resetting slave info succeeded.
    Master failover to 10.0.203.104(10.0.203.104:3358) completed successfully.
    View Code

    ##==========================================##
    MHA在检查时,使用SHOW SLAVE STATUS获取结构中Auto_Position的值来判断是否使用master_auto_position参数来搭建主从复制。

    MHA在切换时,如果使用非GTID模式切换,则在CHANGE MASTER中不会带上参数master_auto_position=0,而如果该从库之前配置为master_auto_position=1,那么CHANGE MASTER会报错,无法正常进行切换。

    因此不能简单修改Server.PM或DBHelper.pm文件来将基于GTID模式切换的群集修改为使用非GTID模式进行切换。

    ##==========================================##

    如果群集因为某种原因导致主从节点上的Executed_Gtid_Set不同,如:

    1、对从库进行直接授权,导致从库比主库拥有更多BINLOG,但该Binlog因各种原因被Purged掉

    2、群集做过版本升级,从未使用GTID的版本升级到GTID版本,从库上曾一段时间内作为主库提供服务,但该时间段日志被Purged掉

    有上诉类似问题时,将从库提升为主库并使用master_auto_position=1来配置复制,复制会因为新主库无法提供足够BINLOG事件而失败。

    处理办法:

    1、通过RESET MASTER和SET GLOBAL gtid_purged=''使得所有节点拥有相同的GTID 集合

    2、将所有复制修改为基于POS点搭建的复制。

    ##==========================================##

  • 相关阅读:
    iOS开发~UI布局(二)storyboard中autolayout和size class的使用详解
    iOS开发~UI布局(一)初探Size Class
    OC登陆界面登陆按钮动画
    Git学习 --> 个人常用命令add,commit以及push
    Git使用之设置SSH Key
    【iOS开发】多屏尺的自动适配 AutoLayout (纯代码方式)
    iOS网络检测Reachability 使用 Demo,可检测2、3、4G
    iOS提醒用户进入设置界面进行重新授权通知定位等功能
    iOS中 @synthesize 和 @dynamic 区别
    iOS 开发笔记
  • 原文地址:https://www.cnblogs.com/TeyGao/p/9284806.html
Copyright © 2020-2023  润新知