MySQL在做主从复制时如何使用GTID

本文主要给大家介绍MySQL在做主从复制时如何使用GTID，希望可以给大家补充和更新些知识，如有其它问题需要了解的可以持续在开发云行业资讯里面关注我的更新文章的。MySQL在5.6后多了一个新的功能就是在做主从复制时使用GTID，和传统的使用relaylog中指定log_pos+log_file的主从复制相比，在使用GTID做主从复制时可以不指定slave需求读取master中的哪一个binlog和偏移量。在传统的MySQL主从复制中，一旦指定错误master的偏移量后，那么就会造成主从不一致，而在基于GTID做的主从复制中就不会发生这样的问题。GTID实际上是master提交了一次事务后而产生的ID，所以在配置的过程中一般都会开启enforce_gtid_consistency（强制事务一致）的配置参数以确保GTID的安全，但是需要注意的是如果开启了开启enforce_gtid_consistency，那么在在事务中就不能创建和删除临时表，这一点需要注意，如创建临时表：除此外还会开启log_slave_updates，这个变量在master和slave中都会开启，除此之外毋庸置疑的是一定需要开启binlog，至于其它大体和log_pos+log_file的主从复制类似，在此就说以一下不一样的地方，至于其它的以前有说过log_pos+log_file的主从复制需要的可以参看:http://jim123.blog.51cto.com/4763600/1862808，在master和slave中开启GTID的相关变量，当然如果是允许重启的话先配置好二者my.cnf是更好的，其中二者的my.cnf的[mysqld]下都需要添加的是：其处，在配置的过程中最好把master的写入关闭，开启只读：在开启相应的变量参数后，在slave上做GTID的主从复制时使用ma开发云主机域名ster_auto_position会根据GTID找到log_pos+log_file，相比传统的方式更为的方便
在开启后可以查看GTID参数变量：当然为了服务高可用，在使用GTID时MySQL也会开启log_pos+log_file，只是我们就不需要想以前那样手动指向log_pos+log_file，因此使用GTID的方式做主从复制修复时还和以前不一样：当然这个是基于GTID和binlog结合的恢复方式，在选择主从复制的方式只要选择其中一中恢复即可，如果只是业务不繁忙的情况下仅有少量的或没有事务时也可以尝试着使用跳过事务的方式来解决错误：此外需要注意的是在使用MySQL的GTID时是不支持GTID直接动态关闭，如果需要关闭则需要使用GTID的4种状态：正常的开启和关闭流程是：OFF OFF_PERMISSIVE ON_PERMISSIVE ON，即最后，需要注意的是在开启GTID复制时多个线程仅会使用一个事务，实际如果开启多线程复制时还是多线程复制，只是在查看线程列表时显示的是只有一个。
看了以上关于MySQL在做主从复制时如何使用GTID，希望能给大家在实际运用中带来一定的帮助。本文由于篇幅有限，难免会有不足和需要补充的地方，如有需要更加专业的解答，可在官网联系我们的24小时售前售后，随时帮您解答问题的。

相关推荐: mydumper使用参考

mydumper导出和导入有诸多优点，特别是在并行方面，网上文章很多，不做过多解释，不过随着mysqlpump的发布和增强，mydumper在并行方面优势将不复存在，以下为mydumper的日常使用，仅记录做参考：mydumper下载地址，直接下载rpm包进行…