Relay

MySQL在5.6版本推出了GTID复制，相比传统的复制，GTID复制对于运维更加友好，这个事物是谁产生，产生多少事物，非常直接的标识出来。 今天将讨论一下 关于从库show slave status 中的Retrieved_Gtid_Set 和 Executed_Gtid_Set. Retrieved_Gtid_Set : 从库已经接收到主库的事务编号 Executed_Gtid_Set : 从库自身已经执行的事务编号 下面将解释这两列的含义： 首先看看master和slave的server-uuid Master: [root@localhost][db1]> show variables like '%uuid%'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 2a09ee6e-645d-11e7-a96c-000c2953a1cb | +---------------+--------------------------------------+ 1 row in set (0.00 sec) Slave

mysql> START GROUP_REPLICATION; ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log. mysql> 查看日志: 2019-10-24T08:33:41.605526Z 7 [Note] [MY-011546] [Repl] Plugin group_replication reported: 'auto_increment_increment is set to 7' 2019-10-24T08:33:41.605545Z 7 [Note] [MY-011547] [Repl] Plugin group_replication reported: 'auto_increment_offset is set to 1' 2019-10-24T08:33:41.605631Z 12 [Note] [MY-010581] [Repl] Slave SQL thread for channel 'group_replication_applier' initialized, starting replication in log 'FIRST' at

1 介绍 MySQL Group Replication（简称MGR）是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MySQL组复制提供了高可用、高扩展、高可靠的MySQL集群服务。 高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证； 高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制； 高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息； 高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。 MGR是MySQL数据库未来发展的一个重要方向。 2 环境准备 操作系统centos7 192.168.200.111　　mysql-5.7 181 192.168.200.112　　mysql-5.7　　182 192.168.200.113　　mysql-5.7　　183 2.2 二进制安装MySQL 省略 2.3 设置hostname和ip映射 [root@server2 ~]# vim /etc

【背景介绍】 故障方描述：一次用户刷权限的时候不小心把数据库用户表记录删掉了，执行之后发现不对后重建用户，杀掉进程后重新MGR启动报错。 【报错信息】 2018-06-13T12:47:41.405593Z 32 [Note] Plugin group_replication reported: 'Group communication SSL configuration: group_replication_ssl_mode: "DISABLED"' 2018-06-13T12:47:41.405820Z 32 [Note] Plugin group_replication reported: '[GCS] Added automatically IP ranges 127.0.0.1/8,172.xx.xxx.xxx/26,192.xxx.xx.xxx/24 to the whitelist' 2018-06-13T12:47:41.406172Z 32 [Note] Plugin group_replication reported: '[GCS] SSL was not enabled' 2018-06-13T12:47:41.406216Z 32 [Note] Plugin group_replication reported: 'Initialized group

Chapter 17 Group Replication Table of Contents 17.1 Group Replication Background 17.1.1 Replication Technologies 17.1.2 Group Replication Use Cases 17.1.3 Group Replication Details 17.2 Getting Started 17.2.1 Deploying Group Replication in Single-Primary Mode 17.2.2 Deploying Group Replication Locally 17.3 Monitoring Group Replication 17.3.1 Group Replication Server States 17.3.2 The replication_group_members Table 17.3.3 The replication_group_member_stats Table 17.4 Group Replication Operations 17.4.1 Deploying in Multi-Primary or Single-Primary Mode 17.4.2 Tuning Recovery 17.4.3 Network

GTID复制原理： 基于GTID的复制是MySQL 5.6后新增的复制方式. GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID. 在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致. 而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次. GTID是由server_uuid和事物id组成，格式为：GTID=server_uuid:transaction_id。server_uuid是在数据库启动过程中自动生成，每台机器的server-uuid不一样。uuid存放在数据目录的auto.conf文件中，而transaction_id就是事务提交时系统顺序分配的一个不会重复的序列号。 GTID的好处： （1）GTID使用master_auto_position=1代替了binlog和position号的主从复制搭建方式，相比binlog和position方式更容易搭建主从复制。 （2）GTID方便实现主从之间的failover，不用一步一步的去查找position和binlog文件。

1. 部署 GTID 全局事务标识 mysql 5.6 加入 1.1 准备 配置文件 # # gtid repl config need server_id=52 # 开启gtid gtid_mode= on # 开启基于gtid复制 enforce_gtid_consistency= on log -bin=mysql52- bin # slave端日志 log-slave-updates=1 binlog_format = row # slave启动时不会自动开启复制 skip-slave-start=1 # choice expire_logs_days =20 重启数据库 （5.7.6以上可以动态而不重启） 权限 GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'replrepl'@'10.27.%' iDENTIFIED BY 'gtidpwd' ; 1.2 启动复制 1.2.1 新库所有binglog全 方式 从库上 change master to master_host='10.27.247.52',master_port=3306,master_user='replrepl',master_password='gtidpwd',master_auto_position=1; start slave 1.2

背景： MySQL5.7在主从复制上面相对之前版本多了一些新特性，包括多源复制、基于组提交的并行复制、在线修改Replication Filter、GTID增强、半同步复制增强等。因为都是和复制相关，所以本文将针对这些新特性放一起进行说明，篇幅可能稍长，本文使用的MySQL版本是5.7.13。 1， 多源复制 （多主一从） MySQL在5.7之后才支持多源复制，之前介绍过 MariaDB 多主一从 搭建测试 说明，现在介绍如何在MySQL上做多主一从，具体的方法说明可以查看 官方文档 。 原理： 多源复制 加入了一个叫做 Channel 的概念， 每一个Channel都是一个独立的Slave，都有一个IO_THREAD和SQL_THREAD。原理和普通复制一样。我们只需要对每一个Master执行Change Master 语句，只需要在每个语句最后使用For Channel来进行区分。由于复制的原理没有改变，在没有开启GTID的时候Master的版本可以是MySQL5.5、5.6、5.7。并且从库需要 master-info-repository 、 relay-log-info-repository 设置为table，否则会报错： ERROR 3077 (HY000): To have multiple channels, repository cannot be of type

MySQL主从同步原理 MySQL主从同步是在MySQL主从复制(Master-Slave Replication)基础上实现的，通过设置在Master MySQL上的binlog(使其处于打开状态)，Slave MySQL上通过一个I/O线程从Master MySQL上读取binlog，然后传输到Slave MySQL的中继日志中，然后Slave MySQL的SQL线程从中继日志中读取中继日志，然后应用到Slave MySQL的数据库中。这样实现了主从数据同步功能。 MySQL中主从复制的优点 横向扩展解决方案 在多个从库之间扩展负载以提高性能。在这种环境中，所有写入和更新在主库上进行。但是，读取可能发生在一个或多个从库上。该模型可以提高写入的性能（由于主库专用于更新），同时在多个从库上读取，可以大大提高读取速度。 数据安全性 由于主库数据被复制到从库，从库可以暂停复制过程，可以在从库上运行备份服务，而不会破坏对应的主库数据。 分析 可以在主库上创建实时数据，而信息分析可以在从库上进行，而不会影响主服务器的性能。 Gtid概念 从 MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。 在原来基于二进制日志的复制中

6月28日任务 说明：有不少同学不能一次性把实验做成功，这是因为还不熟悉，建议至少做3遍 17.1 MySQL主从介绍 17.2 准备工作 17.3 配置主 17.4 配置从 17.5 测试主从同步 有的同学，遇到主从不能正常同步，提示uuid相同的错误。这是因为克隆机器导致。 https://www.2cto.com/database/201412/364479.html 17.1 MySQL主从介绍 MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后，在A上写数据，另外一台B也会跟着写数据，两者数据实时同步的 MySQL主从是基于binlog的，主上须开启binlog才能进行主从。 主从过程大致有3个步骤 1）主将更改操作记录到binlog里 2）从将主的binlog事件(sql语句)同步到从本机上并记录在relaylog里 3）从根据relaylog里面的sql语句按顺序执行 主上有一个log dump线程，用来和从的I/O线程传递binlog 从上有两个线程，其中I/O线程用来同步主的binlog并生成relaylog，另外一个SQL线程用来把relaylog里面的sql语句落地。 MySQL主从原理图 使用场景： 第一种、作为单独数据的备份，因为数据很重要，在主上写一份数据，需要单独在存一份数据，只是针对一台主进行读写操作