gtid运维实战

2022-04-26 17:33:49 阅读：204 来源： 互联网

标签：实战 executed log 运维 SQL host mysql gtid

1.gtid与start slave

help start slave 
    START SLAVE [thread_types] [until_option] [connection_options]
    thread_types:
        [thread_type [, thread_type] ... ]
    thread_type:
        IO_THREAD | SQL_THREAD
    until_option:
        UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set # 1.直到指定的gtid位置停下
              |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos # 2.直到指定的binlog位置停下
              |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos # 3.直到指定的relay log位置停下
              |   SQL_AFTER_MTS_GAPS  } 4.直到slave上多个并行线程之前没有延迟差距了就停下,因为多线程复制，不同线程的复制进度不一样，因此有差距
              
SQL_BEFORE_GTIDS = $gitd_set ： # $gtid_set之前的gtid都会被执行
    eg. 
        START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS='3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56'
        # 表示，当SQL_thread 执行到3E11FA47-71CA-11E1-9E33-C80AA9429562:10 的时候停止，下一个事务是11
        
SQL_AFTER_GTIDS = $gitd_set : # $gtid_set之前，以及$gtid_set包含的gtid都会被执行    
    eg. 
        START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS='3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56'
        # 表示，当SQL_thread 执行到3E11FA47-71CA-11E1-9E33-C80AA9429562:56 的时候停止，56是最后一个提交的事务。


如何从multi-threaded slave 转化成 single-threaded mode
    stop slave sql_thread;
    START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
    SET @@GLOBAL.slave_parallel_workers = 0;
    START SLAVE SQL_THREAD;

2.gtid与upgrade

如果 --gtid-mode=ON ，那么在使用upgrade时候，不推荐使用--write-binlog 选项。
因为，mysql_upgrade会更新Myisam引擎的系统表. 而同时更新transction table 和 non-trasaction table 是gtid所不允许的

3.gtid与mysql.gtid_executed

gtid_mode = (ON|ON_PERMISSIVE), bin_log = off
    gtid 会实时的写入到mysql.gtid_executed表中，且根据executed_gtids_compression_period=N来压缩

gtid_mode = (ON|ON_PERMISSIVE), bin_log = on
    gtid 不会实时的写入到mysql.gtid_executed，executed_gtids_compression_period会失效。
    
    只有当binlog rotate(flush logs;)或者mysql shutdown的时候才会写入mysql.gtid_executed
    如果master异常shutdown，gtid还没有写入到mysql.gtid_executed怎么办呢？这种场景，一般通过mysql recover机制写入到mysql.gtid_executed中
    
注意：
    mysql.gtid_executed表的记录可能并不是完整的已执行GTID，而且有不可访问的可能性（例如误删除此表），因此建议始终通过查询@@global.gtid_executed（每次提交后更新）来确认MySQL服务器的GTID状态，而不是查询mysql.gtid_executed表。
    # 也就是说，mysql.gtid_executed表的信息不是实时记录的，要想获取实时的gtid集合的信息，需要在全局变量中@@global.gtid_executed来获取
    # mysql.gtid_executed表中的gtid是在事务完成之后才写入的，也就是说和事务本身不是原子的，所以一般以@@global.gtid_executed为标准

注意二：
　　启用二进制日志记录时，mysql.gtid_executed表并不保存所有已执行事务的GTID的完整记录，该信息由gtid_executed全局系统变量的值提供。
　　如果服务器意外停止，则当前二进制日志文件中的GTID集不会保存在mysql.gtid_executed表中。在MySQL实例恢复期间，这些GTID将从二进制日志文件添加到表中

换句话说就是，开启了二进制，就将gtid_ececuted的值就录到系统变量@@global_gtid_exectued中
没有开启的二进制的话，就记录在系统表中，但是不是原子操作，有可能少数据

4.gtid与gtid_next

gtid_next的取值为：
    # http://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_gtid_next
    AUTOMATIC: Use the next automatically-generated global transaction ID.
    ANONYMOUS: Transactions do not have global identifiers, and are identified by file and position only.
    A global transaction ID in UUID:NUMBER format.
          
问题：GTID 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-50 对应的事务顺序，从小到大，一定是顺序执行的吗？
    答案：
        不一定。一般情况下事务是从小到大，顺序执行的。 
        但是如果再MTS场景，或者是人工设置gtid_next的情况下，就可能不是顺序执行了


dba:(none)> show master status;
+--------------------+----------+--------------+------------------+-------------------------------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+--------------------+----------+--------------+------------------+-------------------------------------------+
| xx.000009          |     1719 |              |                  | 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-46 |
+--------------------+----------+--------------+------------------+-------------------------------------------+

1 row in set (0.00 sec)
dba:(none)> set gtid_next='0923e916-3c36-11e6-82a5-ecf4bbf1f518:50';
Query OK, 0 rows affected (0.00 sec)
dba:lc> insert into gtid_1 values(5);
Query OK, 1 row affected (0.00 sec)
dba:lc> set gtid_next=AUTOMATIC;
Query OK, 0 rows affected (0.00 sec)
dba:lc> flush logs;
Query OK, 0 rows affected (0.01 sec)

dba:lc> show master status;
+--------------------+----------+--------------+------------------+----------------------------------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                            |
+--------------------+----------+--------------+------------------+----------------------------------------------+
| xx.000010          |      210 |              |                  | 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-46:50 |
+--------------------+----------+--------------+------------------+----------------------------------------------+

1 row in set (0.00 sec)
dba:lc> insert into gtid_1 values(6);
Query OK, 1 row affected (0.00 sec)
dba:lc> insert into gtid_1 values(6);
Query OK, 1 row affected (0.00 sec)
dba:lc> insert into gtid_1 values(6);
Query OK, 1 row affected (0.00 sec)
dba:lc> show master status;

+--------------------+----------+--------------+------------------+-------------------------------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+--------------------+----------+--------------+------------------+-------------------------------------------+
| xx.000010          |     1125 |              |                  | 0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-50 |
+--------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

在这里面，很明显0923e916-3c36-11e6-82a5-ecf4bbf1f518:1-50 事务执行顺序为： 1-46(最先执行) ， 50（其次执行） ， 47-49（最后执行）

5.gtid与mha

GTID模式下，需要relay-log吗？purge_relay_log设置为on可以吗？
# replication 架构
    host_1(host_1:3306) (current master)
        +--host_2(host_2:3306 candidate master)
        +--host_3(host_3:3306 no candidate)
 
 
# 模拟：
    1.大量并发的写入，一直持续的往host_1写数据,造成并发写入很大的样子
    2.host_2：stop slave，造成host_2 延迟master很多的样子
    3.host_1: purge binary logs， 造成master删掉了日志，导致host_2 修复的时候拿不到master的最新binlog
    4.host_3:  一直正常同步master，拥有最新的binlog
    5.host_3: flush logs; purge_relay_log=on; flush logs；一直循环flush logs，造成host_3已经将最新的relay log删掉了，host_2 是肯定拿不到host_3的relay 来修复自己了
    6.好了，一切条件均已经准备完毕，这个时候让master 宕机，这样就能模拟出在relay log没有的情况下，是否可以正常完成mha 切换了
    ...............
    7.结果完成了正常切换，那mha是怎么再gtid模式下，在没有relay log的情况下，正常切换的恩？
    8.原理：host_2发现自己不是最新的slave，所以就去change master到host_3,通过host_3的binlog来恢复
    9.最后，当host_2和host_3都一致的情况下，再让host_3 重新指向host_2，完毕...

结论： gtid模式下，mha恢复切换的原理是不需要relay log的，只需要binlog

pass

标签：实战,executed,log,运维,SQL,host,mysql,gtid
来源： https://www.cnblogs.com/p0st/p/16195655.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

gtid运维实战