家政月嫂网站源码,迅速提高网站排名,网站上线 邮件群发模板,网站建设经验交流材料一主多从的切换正确性
Hi#xff0c;我是阿昌#xff0c;今天学习记录的是关于一主多从的切换正确性的内容。
在切换任务的时候#xff0c;要先主动跳过这些错误#xff0c;通过主动跳过一个事务或者直接设置跳过指定的错误#xff0c;用GTID解决找同步位点的问题
大多…一主多从的切换正确性
Hi我是阿昌今天学习记录的是关于一主多从的切换正确性的内容。
在切换任务的时候要先主动跳过这些错误通过主动跳过一个事务或者直接设置跳过指定的错误用GTID解决找同步位点的问题
大多数的互联网应用场景都是读多写少因此负责的业务在发展过程中很可能先会遇到读性能的问题。一主多从的查询逻辑正确性的方法。
如图 1 所示就是一个基本的一主多从结构。 图中虚线箭头表示的是主备关系也就是 A 和 A’互为主备 从库 B、C、D 指向的是主库 A。
一主多从的设置一般用于读写分离主库负责所有的写入和一部分读其他的读请求则由从库分担。
在一主多从架构下主库故障后的主备切换问题。
如图 2 所示就是主库发生故障主备切换后的结果。 相比于一主一备的切换流程一主多从结构在切换完成后A’会成为新的主库从库 B、C、D 也要改接到 A’。
正是由于多了从库 B、C、D 重新指向的这个过程所以主备切换的复杂性也相应增加了。 一、基于位点的主备切换
切换系统会怎么完成一主多从的主备切换过程。
当把节点 B 设置成节点 A’的从库的时候需要执行一条 change master 命令
CHANGE MASTER TO
MASTER_HOST$host_name
MASTER_PORT$port
MASTER_USER$user_name
MASTER_PASSWORD$password
MASTER_LOG_FILE$master_log_name
MASTER_LOG_POS$master_log_pos 这条命令有这么 6 个参数
MASTER_HOST、MASTER_PORT、MASTER_USER 和 MASTER_PASSWORD 四个参数分别代表了主库 A’的 IP、端口、用户名和密码。最后两个参数 MASTER_LOG_FILE 和 MASTER_LOG_POS 表示要从主库的 master_log_name 文件的 master_log_pos 这个位置的日志继续同步。而这个位置就是所说的同步位点也就是主库对应的文件名和日志偏移量。
节点 B 要设置成 A’的从库就要执行 change master 命令就不可避免地要设置位点的这两个参数但是这两个参数到底应该怎么设置呢
原来节点 B 是 A 的从库本地记录的也是 A 的位点。但是相同的日志A 的位点和 A’的位点是不同的。
因此从库 B 要切换的时候就需要先经过“找同步位点”这个逻辑。这个位点很难精确取到只能取一个大概位置。为什么这么说呢
分析一下看看这个位点一般是怎么获取到的就清楚其中不精确的原因了。
考虑到切换过程中不能丢数据所以我们找位点的时候总是要找一个“稍微往前”的然后再通过判断跳过那些在从库 B 上已经执行过的事务。
一种取同步位点的方法是这样的
等待新主库 A’把中转日志relay log全部同步完成在 A’上执行 show master status 命令得到当前 A’上最新的 File 和 Position取原主库 A 故障的时刻 T用 mysqlbinlog 工具解析 A’的 File得到 T 时刻的位点。
mysqlbinlog File --stop-datetimeT --start-datetimeT图中end_log_pos 后面的值“123”表示的就是 A’这个实例在 T 时刻写入新的 binlog 的位置。
然后可以把 123 这个值作为 $master_log_pos 用在节点 B 的 change master 命令里。当然这个值并不精确。为什么呢
可以设想有这么一种情况假设在 T 这个时刻主库 A 已经执行完成了一个 insert 语句插入了一行数据 R并且已经将 binlog 传给了 A’和 B然后在传完的瞬间主库 A 的主机就掉电了。
那么这时候系统的状态是这样的
在从库 B 上由于同步了 binlog R 这一行已经存在在新主库 A’上 R 这一行也已经存在日志是写在 123 这个位置之后的在从库 B 上执行 change master 命令指向 A’的 File 文件的 123 位置就会把插入 R 这一行数据的 binlog 又同步到从库 B 去执行。
这时候从库 B 的同步线程就会报告 Duplicate entry ‘id_of_R’ for key ‘PRIMARY’ 错误提示出现了主键冲突然后停止同步。 所以通常情况下在切换任务的时候要先主动跳过这些错误有两种常用的方法。
一种做法是主动跳过一个事务。
跳过命令的写法是
set global sql_slave_skip_counter1;
start slave;因为切换过程中可能会不止重复执行一个事务所以需要在从库 B 刚开始接到新主库 A’时持续观察每次碰到这些错误就停下来执行一次跳过命令直到不再出现停下来的情况以此来跳过可能涉及的所有事务。
另外一种方式是通过设置 slave_skip_errors 参数直接设置跳过指定的错误。
在执行主备切换时有这么两类错误是经常会遇到的
1062 错误是插入数据时唯一键冲突1032 错误是删除数据时找不到行。
因此可以把 slave_skip_errors 设置为 “1032,1062”这样中间碰到这两个错误时就直接跳过。
这里需要注意的是这种直接跳过指定错误的方法针对的是主备切换时由于找不到精确的同步位点所以只能采用这种方法来创建从库和新主库的主备关系。
这个背景是很清楚在主备切换过程中直接跳过 1032 和 1062 这两类错误是无损的所以才可以这么设置 slave_skip_errors 参数。
等到主备间的同步关系建立完成并稳定执行一段时间之后还需要把这个参数设置为空以免之后真的出现了主从数据不一致也跳过了。 二、GTID
通过 sql_slave_skip_counter 跳过事务和通过 slave_skip_errors 忽略错误的方法虽然都最终可以建立从库 B 和新主库 A’的主备关系但这两种操作都很复杂而且容易出错。所以MySQL 5.6 版本引入了 GTID彻底解决了这个困难。
那么GTID 到底是什么意思又是如何解决找同步位点这个问题呢
GTID 的全称是 Global Transaction Identifier也就是全局事务 ID是一个事务在提交的时候生成的是这个事务的唯一标识。
它由两部分组成格式是
GTIDserver_uuid:gno其中
server_uuid 是一个实例第一次启动时自动生成的是一个全局唯一的值gno 是一个整数初始值是 1每次提交事务的时候分配给这个事务并加 1。
在 MySQL 的官方文档里GTID 格式是这么定义的
GTIDsource_id:transaction_id这里的 source_id 就是 server_uuid而后面的这个 transaction_id觉得容易造成误导所以改成了 gno。
为什么说使用 transaction_id 容易造成误解呢因为在 MySQL 里面说 transaction_id 就是指事务 id事务 id 是在事务执行过程中分配的如果这个事务回滚了事务 id 也会递增而 gno 是在事务提交的时候才会分配。
从效果上看GTID 往往是连续的因此用 gno 来表示更容易理解。
GTID 模式的启动也很简单只需要在启动一个 MySQL 实例的时候加上参数 gtid_modeon 和 enforce_gtid_consistencyon 就可以了。
在 GTID 模式下每个事务都会跟一个 GTID 一一对应。
这个 GTID 有两种生成方式而使用哪种方式取决于 session 变量 gtid_next 的值。
如果 gtid_nextautomatic代表使用默认值。这时MySQL 就会把 server_uuid:gno 分配给这个事务。 a. 记录 binlog 的时候先记录一行 SET SESSION.GTID_NEXT‘server_uuid:gno’;b. 把这个 GTID 加入本实例的 GTID 集合。 如果 gtid_next 是一个指定的 GTID 的值比如通过 set gtid_nextcurrent_gtid’指定为 current_gtid那么就有两种可能 如果 current_gtid 已经存在于实例的 GTID 集合中接下来执行的这个事务会直接被系统忽略如果 current_gtid 没有存在于实例的 GTID 集合中就将这个 current_gtid 分配给接下来要执行的事务也就是说系统不需要给这个事务生成新的 GTID因此 gno 也不用加 1。注意一个 current_gtid 只能给一个事务使用。
这个事务提交后如果要执行下一个事务就要执行 set 命令把 gtid_next 设置成另外一个 gtid 或者 automatic。
这样每个 MySQL 实例都维护了一个 GTID 集合用来对应“这个实例执行过的所有事务”。
这样看上去不太容易理解接下来就用一个简单的例子来和说明 GTID 的基本用法。
在实例 X 中创建一个表 t。
CREATE TABLE t (id int(11) NOT NULL,c int(11) DEFAULT NULL,PRIMARY KEY (id)
) ENGINEInnoDB;insert into t values(1,1);可以看到事务的 BEGIN 之前有一条 SET SESSION.GTID_NEXT 命令。
这时如果实例 X 有从库那么将 CREATE TABLE 和 insert 语句的 binlog 同步过去执行的话执行事务之前就会先执行这两个 SET 命令 这样被加入从库的 GTID 集合的就是图中的这两个 GTID。
假设现在这个实例 X 是另外一个实例 Y 的从库并且此时在实例 Y 上执行了下面这条插入语句
insert into t values(1,1);并且这条语句在实例 Y 上的 GTID 是 “aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”。
那么实例 X 作为 Y 的从库就要同步这个事务过来执行显然会出现主键冲突导致实例 X 的同步线程停止。
这时应该怎么处理呢
处理方法就是可以执行下面的这个语句序列
set gtid_nextaaaaaaaa-cccc-dddd-eeee-ffffffffffff:10;
begin;
commit;
set gtid_nextautomatic;
start slave;其中前三条语句的作用是通过提交一个空事务把这个 GTID 加到实例 X 的 GTID 集合中。
如图 5 所示就是执行完这个空事务之后的 show master status 的结果。 可以看到实例 X 的 Executed_Gtid_set 里面已经加入了这个 GTID。
这样再执行 start slave 命令让同步线程执行起来的时候虽然实例 X 上还是会继续执行实例 Y 传过来的事务但是由于“aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”已经存在于实例 X 的 GTID 集合中了所以实例 X 就会直接跳过这个事务也就不会再出现主键冲突的错误。
在上面的这个语句序列中start slave 命令之前还有一句 set gtid_nextautomatic。
这句话的作用是“恢复 GTID 的默认分配行为”也就是说如果之后有新的事务再执行就还是按照原来的分配方式继续分配 gno3。 三、基于 GTID 的主备切换
在 GTID 模式下备库 B 要设置为新主库 A’的从库的语法如下
CHANGE MASTER TO
MASTER_HOST$host_name
MASTER_PORT$port
MASTER_USER$user_name
MASTER_PASSWORD$password
master_auto_position1 其中master_auto_position1 就表示这个主备关系使用的是 GTID 协议。
头疼不已的 MASTER_LOG_FILE 和 MASTER_LOG_POS 参数已经不需要指定了。
把现在这个时刻实例 A’的 GTID 集合记为 set_a实例 B 的 GTID 集合记为 set_b。
在实例 B 上执行 start slave 命令取 binlog 的逻辑是这样的
实例 B 指定主库 A’基于主备协议建立连接。实例 B 把 set_b 发给主库 A’。实例 A’算出 set_a 与 set_b 的差集也就是所有存在于 set_a但是不存在于 set_b 的 GTID 的集合判断 A’本地是否包含了这个差集需要的所有 binlog 事务。 a. 如果不包含表示 A’已经把实例 B 需要的 binlog 给删掉了直接返回错误b. 如果确认全部包含A’从自己的 binlog 文件里面找出第一个不在 set_b 的事务发给 B 之后就从这个事务开始往后读文件按顺序取 binlog 发给 B 去执行。
其实这个逻辑里面包含了一个设计思想
在基于 GTID 的主备关系里系统认为只要建立主备关系就必须保证主库发给备库的日志是完整的。
因此如果实例 B 需要的日志已经不存在A’就拒绝把日志发给 B。这跟基于位点的主备协议不同。
基于位点的协议是由备库决定的备库指定哪个位点主库就发哪个位点不做日志的完整性判断。 基于上面的介绍再来看看引入 GTID 后一主多从的切换场景下主备切换是如何实现的。
由于不需要找位点了所以从库 B、C、D 只需要分别执行 change master 命令指向实例 A’即可。
其实严谨地说主备切换不是不需要找位点了而是找位点这个工作在实例 A’内部就已经自动完成了。
但由于这个工作是自动的所以对 HA 系统的开发人员来说非常友好。
之后这个系统就由新主库 A’写入主库 A’的自己生成的 binlog 中的 GTID 集合格式是server_uuid_of_A’:1-M。
如果之前从库 B 的 GTID 集合格式是 server_uuid_of_A:1-N 那么切换之后 GTID 集合的格式就变成了 server_uuid_of_A:1-N, server_uuid_of_A’:1-M。
当然主库 A’之前也是 A 的备库因此主库 A’和从库 B 的 GTID 集合是一样的。这就达到了预期。 四、GTID 和在线 DDL
举个例子来理解 GTID。
MySQL 有哪些“饮鸩止渴”提高性能的方法提到业务高峰期的慢查询性能问题时分析到如果是由于索引缺失引起的性能问题可以通过在线加索引来解决。但是考虑到要避免新增索引对主库性能造成的影响可以先在备库加索引然后再切换。
当时说在双 M 结构下备库执行的 DDL 语句也会传给主库为了避免传回后对主库造成影响要通过 set sql_log_binoff 关掉 binlog。
这样操作的话数据库里面是加了索引但是 binlog 并没有记录下这一个更新是不是会导致数据和日志不一致
假设这两个互为主备关系的库还是实例 X 和实例 Y且当前主库是 X并且都打开了 GTID 模式。
这时的主备切换流程可以变成下面这样
在实例 X 上执行 stop slave。在实例 Y 上执行 DDL 语句。注意这里并不需要关闭 binlog。执行完成后查出这个 DDL 语句对应的 GTID并记为 server_uuid_of_Y:gno。到实例 X 上执行以下语句序列
set GTID_NEXTserver_uuid_of_Y:gno;
begin;
commit;
set gtid_nextautomatic;
start slave;这样做的目的在于既可以让实例 Y 的更新有 binlog 记录同时也可以确保不会在实例 X 上执行这条更新。 五、问题 在 GTID 模式下设置主从关系的时候从库执行 start slave 命令后主库发现需要的 binlog 已经被删除掉了导致主备创建不成功。 这种情况下你觉得可以怎么处理呢 解决办法 从库B在启动同步前需要设置 gtid_purged指定GTID同步的起点使用备份搭建从库时需要这样设置。 如果在从库上执行了单独的操作导致主库上缺少GTID那么可以在主库上模拟一个与从库B上GTID一样的空事务这样主从同步就不会报错了。
