一、gtid特性介绍：
GTID(global transaction identifier)是MySQL 5.6的新特性，可以唯一的标识一个事务，由UUID+TID组成：
在主从复制中，GTID代替了classic的复制方法，不再使用binlog+pos开启复制，而是使用master_auto_postion = 1的方式自动匹配GTID断点进行复制。
要开启GTID，只需在MySQL参数文件中添加以下参数：
二、数据恢复需求：
需要将MySQL(以下简称A库)恢复到一天前的凌晨12:00左右的状态 需要具备的前提条件如下：
三、恢复操作：
在另一台MySQL(B库)上进行数据的恢复，这样可以避免影响线上业务
1. 将B库data目录移走，拷贝A库备份文件到B库
2. 开启B库，配置主从
查看data目录下xtrabackup_binlog_info文件中记录的GTID：
在B库(slave)设置@@global.gtid_purged跳过备份包含的GTID，并执行change master to指定A库为主库：
注意： xtrabackup_binlog_info中的GTID有时不止一个，设置@@global.gtid_purged时指定多个即可，以逗号隔开。
四、在A库binlog中找到恢复点并进行恢复
需要特别注意的是，在上述操作后，不要直接start slave，否则B库也又会跑到当前A库的状态
将A库binlog转换为sql语句：
找到前一天凌晨12:00左右的位置并记录GTID：
在B库开启slave并指定恢复到的位置：
当执行到了指定的GTID，SQL线程便会停止，但IO线程还会继续复制：
好啦，想看昨天凌晨的哪些数据呀?都在B库里啦~~~
附：常见问题
在设置@@global.gtid_purged时，可能会遇到报错：
这是因为这台MySQL的@@GLOBAL.GTID_EXECUTED并不是空的，执行以下reset master操作就好了：
对于含有innodb表的实例进行文件拷贝备份时必须停mysql实例吗
在实际环境中，时不时需要备份恢复单个或多个表（注意：这里除非明确指定，所说的表一律指InnoDB表），而对于innodb引擎恢复单个表需要整体的恢复，xtrabackup也可以单个表恢复，只不过是用的正则过滤的，不知最新版本是否支持表空间传输特性。 本文将要说说怎么移动或复制部分或全部的表到另一台服务器上，而所要用到的技术点就是transportable tablespace特性，这就意味着MySQL5.6.6以及以上版本才支持。 表空间传输特性允许表空间从一个实例移动到另一个实例上。 这在以前版本上，这对InnoDB表空间是不可能的，因为所有的表数据都是系统表空间的一部分。 在MySQL5.6.6以及更改版本，FLUSH TABLES ... for EXPORT 语法准备将InnoDB表复制到另一台服务器，然后在另一台服务器上执行ALTER TABLE ... DISCARD TABLESPACE 和 ALTER TABLE ... IMPORT TABLESPACE 将数据导入。 将 和 文件复制过去，用于在导入时更新表元数据，如空间ID。 使用限制和说明innodb_file_per_table必须设置为on，在 MySQL5.6.6版本默认是开启的。 居留在共享系统表空间的表不能静默。 当表静默时，只有只读事务被允许。 当导入表空间时，页面大小必须与导入实例的页面大小相符合。 DISCARD TABLESPACE 不支持分区表，也就意味着transportable tablespaces 也不支持分区表。 如果在分区表上执行ALTER TABLE ... DISCARD TABLESPACE 将会返回下面的错误信息：ERROR 1031 (HY000): Table storage engine for part doesnt have this option.当foreign_key_checks=1时，DISCARD TABLESPACE 不支持主键外键约束关系。 操作这些表时需要设置为foreign_key_checks。 ALTER TABLE ... IMPORT TABLESPACE 不强制外键约束。 如果表之间有外键约束，所有的表应该在同一个时间点被导出。 ALTER TABLE ... IMPORT TABLESPACE 导入表空间不要求元数据文件。 然而在导入时缺少了文件元数据检查就无法完成，或返回下面的信息：InnoDB: IO Read error: (2, No such file or directory) Error opening .\test\, will attempt to import without schema verification 1 row in set (0.00 sec) 。 当没有不匹配的表结构时，导入没有文件可能会更方便。 此外，在元数据不能从文件中收集的故障恢复时，导入没有可能更有用的。 导出导入的MySQL版本需要相同。 否则，文件必须要在导入的服务器上创建。 在复制架构中，主和从必须设置innodb_file_per_table=1。 在windows中，文件是不区分大小写的，而Linux和unix是区分大小写的，在跨平台导入导出时，需要设置lower_case_table_names=1。 将表空间复制到另一台上此过程将演示如何从一个运行的mysql服务器实例上将表空间复制到另一台上。 假设源实例为server_A，目的实例为server_B。 在server_A上12mysql> use test;mysql> CREATE TABLE ttlsa(id INT) engine=InnoDB;在server_B上12mysql> use test;mysql> CREATE TABLE ttlsa(id INT) engine=InnoDB;在server_B上放弃现有的表空间。 在表空间导入前，InnoDB必须丢弃已连接到接受表的表空间。 1mysql> ALTER TABLE ttlsa DISCARD TABLESPACE;在server_A上执行FLUSH TABLES ... FOR EXPORT语句静默表并生成元数据文件。 FLUSH TABLES ... FOR EXPORT 这个执行之后，会话不能退出，否则cfg自动消失。 12mysql> use test;mysql> FLUSH TABLES ttlsa FOR EXPORT;文件创建在InnoDB数据目录。 在server_A上复制和文件到server_B上1shell> scp /path/to/datadir/test/ttlsa.{ibd,cfg} destination-server:/path/to/datadir/test文件和必须在释放共享锁之前复制。 在server_A上释放FLUSH TABLES ... FOR EXPORT语句锁12mysql> use test;mysql> UNLOCK TABLES;在server_B上导入表空间12mysql> use test;mysql> ALTER TABLE ttlsa IMPORT TABLESPACE;Transportable Tablespace 内幕以下说明在表空间传输过程中的内部和错误日志信息。 当在server_B上执行ALTER TABLE ... DISCARD TABLESPACE该表锁定在X模式下表空间从该表分离当在server_A上执行FLUSH TABLES ... FOR EXPORT表锁定在共享模式下purge coordinator 线程停止脏页被同步到磁盘上表元数据写入到二进制文件中日志信息如下：1234[Note] InnoDB: Sync to disk of started.[Note] InnoDB: Stopping purge[Note] InnoDB: Writing table metadata to ./test/[Note] InnoDB: Table flushed to disk当在server_A上执行UNLOCK TABLES二进制文件将删除共享锁将释放，purge coordinator 线程将重启日志信息如下：12[Note] InnoDB: Deleting the meta-data file ./test/[Note] InnoDB: Resuming purge当在server_B上执行ALTER TABLE ... IMPORT TABLESPACE每个表空间页面将检查损坏每个空间ID和日志序号（LSN）将更新标志有效的和LSN更新头页Btree页将更新页面状态被设置为脏将被写入到磁盘日志信息如下：[Note] InnoDB: Importing tablespace for table test/ttlsa that was exported from host ubuntu[Note] InnoDB: Phase I - Update all pages[Note] InnoDB: Sync to disk[Note] InnoDB: Sync to disk - done![Note] InnoDB: Phase III - Flush changes to disk[Note] InnoDB: Phase IV - Flush complete
mysql如何快速备份
来源：知乎河南-老宋(志强)问题描述的不是非常的清晰使用mysqldump备份时一般会会加上--single-transaction参数，这里假设你是加了这个参数。 一 加速备份1 加了single-transaction参数 备份时 需要先flush table with read lock 这个过程中会有一个锁表的过程，如果有事务或语句正在执行，没有结束，那么备份进程会一直等待，并且阻塞别的事务，那么也会影响业务。 所以要先确认备份的时候没有大的事务在运行。 具体 single-transaction的加锁可以参考 我的博客：mysqldump备份时加single-transaction会不会加锁2 mysqldump是单进程的，没有办法并行，但现在机器的瓶颈多是出现在IO方面，可以使用更了的IO设备加快速度3 mysqldump时如果空间够的话，不要边压缩边备份二 加速恢复1 关闭binlog:不写入Binlog会大大的加快数据导入的速度2 innodb_flush_log_at_trx_commit=03 更好的配置建议：一 如果非要使用逻辑备份，可以考虑mysqldumper, mysqlpump(5.7)这两个工具去备份，这两个在备份的时候支持并行操作，mysqldumper还可以对单表进行恢复，在只需要恢复单表的情况下，恢复速度会大大加快二 使用物理备份 xtrabackup (open source),MEB(oracle提供，收费)： 他们的备份原理是基于mysql crash recover， 备份速度 是和逻辑备份的相差不太大。 但是恢复速度却有很大的提升。 逻辑备份 备出来的是sql语句文件，恢复时需要一条一条的执行sql,所以恢复很慢。 而物理备份和还原的速度 相当于直接copy文件，所以恢复的时候性能有很大的提升并且这两个软件还支持并行，效果更好。 逻辑备份最大的优点是 备份好的文件经压缩后占用空间较小，最大缺点恢复太慢物理备份可以很快的恢复，但是备份好的文件压缩后占用空间比逻辑备份要大。 使用云，你做为用户可以不用考虑这些事情。 附：xtrabackup的并行参数Parallel local backupsParallel compressionParallel encryptionParallel apply-logGary Chen《MySQL DBA修炼之道》作者。 从事数据库领域10多年。 1.一般来说,你只有靠更好的硬件. 软件没有大的变动的情况下不可能突破硬件瓶颈;2. mysqldump默认的导出选项已经可以了,单进程的工具不要期望太多,TommyChiu介绍的工具可试试.;3. 导出的时候观察下系统,如果是cpu瓶颈,你基本无解.如果是swap问题,看是否是因为内存不够;4. 恢复的时候主要是一个参数:innodb_flush_log_at_trx_commit=2TommyChiumk-parallel-dump 试试
mysql如何实现两个数据库数据结构实时同步？
1、如果RDS上的数据没有发生增删改的操作的话，可以生成物理备份或者逻辑备份，然后将物理备份和逻辑备份通过Xtrabackup或者mysqldump将数据导入到自建库。 2、如果在物理备份已经生成后对于数据库仍然有增删改的操作的话，则需要您在恢复物理备份后还需要追加后续的binlog文件，可以通过API/控制台获取binlog文件去追加增量数据。 这里有一个非常需要注意的一点是在解压出来物理备份文件后除了数据和索引文件外还有得到如下图中的一些文件。 由于在物理备份上应用binlog是需要记录binlog的pos点的，所有的RDS都是采用主备架构保证高可用性的，为保证主库正常对外提供服务，备份操作是在从库上执行的，但是生成出来的binlog文件却既有可能是主库或者从库上生成（两个binlog文件的pos点是不一致的）。 提供给用户的也可能是这里面的任意一份，因此在物理备份文件中给用户提供了两个binlog文件的pos点，如下图：用户在应用binlog的时候需要两个pos点都测试一下，哪个pos点可以在binlog中找到从这个pos点开始应用binlog。 3、用户想要将RDS上的增量数据同步在自建库的binlog上可以使用DTS的数据订阅功能，可以通过SDK消费增量数据即可再自己应用该数据。
发表评论