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,那么在在事务中就不能创建和删除临时表,这一点需要注意,如创建临时表:

create temporary table
建议改成
create table

除此外还会开启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]下都需要添加的是:

log_slave_updates = on
gtid_mode = on
enforce_gtid_consistency = on
在slave下建议开启只读:
read_only = on

其处,在配置的过程中最好把master的写入关闭,开启只读:

mysql> set global read_only = ON;
Query OK, 0 rows affected (0.00 sec)

在开启相应的变量参数后,在slave上做指向和log_pos+log_file的主从复制相比只要使用master_auto_position即可

change master to master_host=‘192.168.168.253‘,master_user=‘test_backup‘,master_password=‘test_backup‘,master_auto_position = 1;

在开启后可以查看GTID参数变量:

mysql> show global variables like ‘%GTID%‘;
时间: 2024-10-20 02:44:44

MySQL的GTID复制的相关文章

深入MySQL复制(二):基于GTID复制

相比传统的MySQL复制,gtid复制无论是配置还是维护都要轻松的多.本文对gtid复制稍作介绍. MySQL基于GTID复制官方手册:https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html 1.gtid基本概念 传统的基于binlog position复制的方式有个严重的缺点:如果slave连接master时指定的binlog文件错误或者position错误,会造成遗漏或者重复,很多时候前后数据是有依赖性的,这样就会出错而导

Mysql的ab复制

mysql复制在业界里有叫:mysql同步,ab复制等.专业名称就是叫:复制.复制是单向的异步复制,从一个Mysql(Master)复制到另一个Mysql(Slave).实现整个主从复制,需要由Master服务器上的IO进程,和Salve服务器上的Sql进程和IO进程共同完成. 要实现主从复制,首先必须打开Master端的二进制日志(bin-log)功能,因为整个Mysql复制过程实际上就是Slave从Master端获取相应的二进制日志文件,然后在根据相应的Position号在自己Slave端完

mariadb10.x启用gtid复制时提示mysql.gtid_slave_pos找不到的解决方案

mariadb10.x安装方式为yum时,当启用gtid复制方式后,一直提示mysql.gtid_slave_pos找不到的解决方案 造成的原因不详 解决方案:/usr/share/mysql/mysql_system_tables.sql是创建系统表的脚本 找到innodb_table_stats,innodb_index_stats,gtid_slave_pos表的创建方式 innodb_table_stats表的创建语句: SET FOREIGN_KEY_CHECKS=0; DROP TA

mysql 5.6 的新特性:GTID 复制

mysql 5.6 的新特性: MySQL 5.6 包含了一个复制的新功能,enabling DevOps teams to reliably scale-out their MySQL infrastructure across commodity hardware, rel="nofollow">Global Transaction Identifiers (GTIDs)功能, 为了解决以下问题: -能够无缝的故障恢复和master与slave的切换 -能把slave指向新的

MYSQL 基于GTID的复制

1.概述 从MYSQL5.6 开始,mysql开始支持GTID复制. 基于日志点复制的缺点: 从那个二进制日志的偏移量进行增量同步,如果指定错误会造成遗漏或者重复,导致数据不一致. 基于GTID复制: 1.从服务器会告诉主服务器已执行的事务的GTID值. 2.主库会告诉从哪些GTID事务没有被执行. 同一个事务在指定的从库执行一次. 什么是GTID GTID即全局事务ID,器保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID. GTID=source_id:transaction_i

MySQL 5.6.10 跨平台GTID复制实践

根据业务需要,建立MySQL复制来实现数据冗余. MySQL 5.6.10版本提供了更方便的基于GTID的复制功能,MySQL可以通过GTID自动识别上次同步的点,极大地方便了运维人员,减少出错的几率. 在官方文档中提到,最保险可靠的复制方式,是基于row的复制,所以宁可牺牲一些性能也要保证数据的安全. 现实环境中,master主数据库MySQL 5.6.10(msi安装方式)安装在Windows 2008 Server x64上,slave从服务器是一台老旧的DELL服务器,运行CentOS

基于GTID的MySQL多源复制配置

多源复制的意义 1.可以在一个从库上对多个服务器的数据库进行汇总,或者对一个数据库的分库分表进行汇总. 2.集约使用从库服务器的硬件资源,毕竟弱一个数据库业务量较小确占用整个服务器资源是不经济的. 3.更方便的对个业务库进行数据备份,优化数据库备份脚本编写逻辑 拓补图 实施步骤 1.备份主库上的数据,考虑到gtid的问题建议只采用mysqldump程序进行备份 centos:#mysqldump --login-path=3306 \ #mysql官方工具都支持login-path快速登录   

mysql之 mysql 5.6不停机主从搭建(一主一从基于GTID复制)

环境说明:版本 version 5.6.25-log 主库ip: 10.219.24.25从库ip:10.219.24.22os 版本: centos 6.7已安装热备软件:xtrabackup 防火墙已关 补充: 主从复制原理: http://blog.csdn.net/zhang123456456/article/details/72972701GTID 复制原理: http://blog.csdn.net/zhang123456456/article/details/73002216mys

mysql之 MySQL 主从基于 GTID 复制原理概述

一. 什么是GTID ( Global transaction identifiers ):MySQL-5.6.2开始支持,MySQL-5.6.10后完善,GTID 分成两部分,一部分是服务的UUid,UUID保存在mysql数据目录的auto.cnf文件中,这是一个非常重要的文件,不能删除,这一部分是不会变的.另外一部分就是事务ID了,随着事务的增加,值一次递增,如下图+---------------+----------+--------------+------------------+-