下载文档原格式
MySQL中的主备同步和故障恢复技巧MySQL是一种常用的关系型数据库管理系统，同时也是一个开源项目。
它的主要用途是存储、管理和检索数据。
对于大型企业和组织来说，确保数据库的高可用性和故障恢复是非常重要的。
在MySQL中，主备同步是一种重要的技术手段，用于确保数据库的冗余备份和数据一致性。
它的主要原理是将主数据库中的数据实时同步到备库中，以便在主库发生故障或不可访问时，可以快速切换到备库继续提供服务。
主备同步的实现主要依赖于MySQL的复制技术。
MySQL复制是一种基于日志的复制方法，通过记录和重放日志来实现数据的同步。
在MySQL复制中，主库将更新操作记录到二进制日志（binary log）中，备库通过读取主库的二进制日志并将其应用到自己的数据库上，从而实现数据的同步。
为了确保主备同步的可靠性和性能，我们可以采取一些技巧和优化措施。
首先，我们应该选择合适的同步模式。
MySQL提供了几种同步模式，包括异步复制、半同步复制和组复制。
异步复制是最简单和性能最高的模式，但它可能会导致数据丢失。
半同步复制提供了更好的数据一致性保证，但会牺牲一部分性能。
组复制是MySQL 5.7版本引入的新功能，它允许将多个备库组成一个组，并使用多数原则来保证数据的一致性。
其次，我们应该合理配置MySQL的参数。
在主备同步中，有几个与复制相关的参数需要特别关注。
其中，最重要的是binlog_format参数，它决定了MySQL的二进制日志格式。
MySQL提供了三种二进制日志格式：STATEMENT、ROW和MIXED。
STATEMENT模式下，MySQL将记录SQL语句本身；ROW模式下，MySQL将记录每一行数据的变化；MIXED模式则根据情况选择使用STATEMENT或ROW模式。
选择合适的二进制日志格式可以提高数据库的性能和稳定性。
此外，在主备同步中，还有一些其他的技巧和注意事项需要关注。
首先，我们应该定期备份和检查二进制日志，并设置合适的保存时间和大小。
MySQL常见错误及解决方法总结近年来，MySQL已经成为了最受欢迎的开源数据库管理系统之一。
它的稳定性和可靠性使得它被广泛应用于各种类型的应用程序和网站中。
然而，正如任何其他软件一样，MySQL也存在一些常见的错误和问题。
在本文中，我们将探讨一些常见的MySQL错误以及它们的解决方法。
1. 连接问题在访问MySQL数据库时，经常会遇到无法连接到数据库的问题。
这可能是由多种原因引起的。
首先，确保您的数据库服务器正在运行，并且端口号、用户名和密码等连接信息正确无误。
如果连接信息正确，但仍然无法连接，那么可能是由于网络问题或防火墙设置等导致的。
您可以尝试通过检查网络连接或调整防火墙设置来解决此问题。
2. 数据库备份和恢复问题数据库备份和恢复是任何一个数据库管理员都必须处理的重要任务。
然而，当执行这些操作时，有时会出现各种问题。
例如，在备份过程中可能会遇到文件权限错误或磁盘空间不足等问题。
解决这些问题的方法包括：确保备份目录具有正确的权限，确保磁盘有足够的空间，并且检查备份脚本中的语法错误等。
3. 数据库性能问题数据库性能问题是每个应用程序开发人员和数据库管理员都必须关注的事项。
当数据库查询变得缓慢时，可能会导致应用程序的性能下降。
这可能是由于不正确的查询、索引问题或服务器配置不当引起的。
为解决这些问题，您可以优化查询语句、创建适当的索引和重新配置MySQL服务器的参数等。
4. 主从复制问题在分布式环境中，MySQL的主从复制是常用的数据复制方法之一。
但是，复制过程中可能会遇到各种问题。
例如：复制延迟、数据不一致或复制停止等。
要解决这些问题，您可以检查主从服务器之间的网络连接、确保二进制日志文件正确配置，并且检查复制过程中的错误日志等。
5. 错误日志和慢查询日志MySQL的错误日志和慢查询日志是调试和排查问题的重要工具。
错误日志记录了发生的错误和警告，而慢查询日志记录了执行时间超过指定阈值的查询。
然而，如果您配置不正确，有时可能无法生成这些日志。
详解MySQL双活同步复制四种解决⽅案⽬录对于数据实时同步，其核⼼是需要基于⽇志来实现，是可以实现准实时的数据同步，基于⽇志实现不会要求数据库本⾝在设计和实现中带来任何额外的约束。
基于MySQL原⽣复制主主同步⽅案这是常见的⽅案，⼀般来说，中⼩型规模的时候，采⽤这种架构是最省事的。
两个节点可以采⽤简单的双主模式，并且使⽤专线连接，在master_A节点发⽣故障后，应⽤连接快速切换到master_B节点，反之也亦然。
有⼏个需要注意的地⽅，脑裂的情况，两个节点写⼊相同数据⽽引发冲突，同时把两个节点的auto_increment_increment（⾃增步长）和auto_increment_offset（⾃增起始值）设成不同值。
其⽬的是为了避免master节点意外宕机时，可能会有部分binlog未能及时复制到slave上被应⽤，从⽽会导致slave新写⼊数据的⾃增值和原先master上冲突了，因此⼀开始就使其错开；当然了，如果有合适的容错机制能解决主从⾃增ID冲突的话，也可以不这么做，使⽤更新的数据版本5.7+，可以利⽤多线程复制的⽅式可以很⼤程度降低复制延迟，同时，对复制延迟特别敏感的另⼀个备选⽅案，是semi-sync半同步复制，基本上⽆延迟，不过事务并发性能会有不⼩程度的损失，特别是在双向写的时候，需要综合评估再决定。
基于Galera replication⽅案Galera是Codership提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务⾼可⽤及数据⼀致性，基于Galera的⾼可⽤⽅案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（简称PXC）。
⽬前PXC⽤的会⽐较多⼀些，数据严格⼀致性，尤其适合电商类应⽤，不过PXC也是有其局限性的，如果并发事务量很⼤的话，建议采⽤InfiniBand⽹络，降低⽹络延迟，因为PXC存在写扩⼤以及短板效应，并发效率会有较⼤损失，类似semi-sync半同步复制，Gelera实际只能⽤三个节点，⽹络抖动造成的性能和稳定性习惯性问题基于Group Replication⽅案通过Paxos协议提供数据库集群节点数据强⼀致保证，MGR准确来说是MySQL官⽅推出的⾼可⽤解决⽅案，基于原⽣复制技术，并以插件的⽅式提供，并且集群间所有节点可写⼊，解决了单个集群的写⼊性能，所有节点都能读写，解决⽹络分区导致的脑裂问题，提升复制数据的可靠性，不过现实还是有些残酷，⽬前尝鲜的并不是很多，同时仅⽀持InnoDB表，并且每张表⼀定要有⼀个主键，⽤于做write set的冲突检测，必须打开GTID特性，⼆进制⽇志格式必须设置为ROW，⽤于选主与write setCOMMIT可能会导致失败，类似于快照事务隔离级别的失败场景，⽬前⼀个MGR集群最多⽀持9个节点，不⽀持外键于save point特性，⽆法做全局间的约束检测与部分部分回滚，⼆进制⽇志不⽀持binlog event checksum基于canal⽅案对于数据库的实时同步，阿⾥巴巴专门有⼀个开源项⽬，即otter来实现分布式数据库的同步复制，其核⼼思想仍然是通过获取数据库的增量数据⽇志，来进⾏准实时的同步复制。
mysql主从同步出现异常语句跳过错误处理1.跳过操作：mysql>slave stop;mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 跳过⼀个事务mysql>slave start2.SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1，跳过⼀个事务的概念。
在mysql中，对于sql的 binary log 他实际上是由⼀连串的event组成的⼀个组，即事务组。
我们在master上可以通过SHOW BINLOG EVENTS 来查看⼀个sql⾥有多少个event。
例如：mysql> SHOW BINLOG EVENTS in 'mysql-bin.000003' from 9508\G*************************** 1. row ***************************⼀个row代表⼀个事务组Log_name: mysql-bin.000003Pos: 9508Event_type: QueryServer_id: 2End_log_pos: 9944Info: use `BK`; CREATE DEFINER=`root`@`%` PROCEDURE `zoucm`( in Spwd VARCHAR(20), in Npwd varchar(20), in YH VARCHAR(20))pwd_s:BEGINDECLARE Pid int;select count(*) into Pid from users where user = YH and PWD = Spwd;if Pid=1 THENupdate users set PWD=Npwd where user = YH and PWD = Spwd;select 0 state ;LEAVE pwd_s;ELSEselect 1 as state ;end if;end pwd_s*************************** 2. row ***************************Log_name: mysql-bin.000003Pos: 9944Event_type: QueryServer_id: 2End_log_pos: 10080Info: use `liguanjia_cn`; CREATE TABLE `sss` (`ds` int(11) NULL ,PRIMARY KEY (`ds`))*************************** 3. row ***************************Log_name: mysql-bin.000003Pos: 10080Event_type: QueryServer_id: 2End_log_pos: 10214Info: use `liguanjia_cn`; CREATE TABLE `dd` (`ss` double NULL ,PRIMARY KEY (`ss`))3。
MySQL的主从复制步骤详解及常见错误解决⽅法mysql主从复制(replication同步)现在企业⽤的⽐较多,也很成熟.它有以下优点:1.降低主服务器压⼒,可在从库上执⾏查询⼯作.2.在从库上进⾏备份,避免影响主服务器服务.3.当主库出现问题时,可以切换到从库上.不过,⽤它做备份时就会也有弊端,如果主库有误操作的话,从库也会收到命令.下⾯直接进⼊操作.这⾥使⽤的是debian5操作系统,mysql5.0,默认引擎innodb10.1.1.45 主库10.1.1.43 从库1.设置主库1)修改主库f,这⾥主要是server-id⼀定主从不要设置成⼀样的.打开binlog⽇志log-bin = /opt/log.bin/45server-id = 452)在主服务器上建⽴同步账号mysql> grant REPLICATION SLAVE ON *.* TO 'repl'@'10.1.1.43' IDENTIFIED BY 'replpass';注意:mysql的权限系统在实现上⽐较简单,相关权限信息主要存储在⼏个系统表中:er,mysql.db,mysql.host,mysql.table_priv,mysql.columm_priv.由于权限信息的数据量⽐较⼩,访问⼜⾮常频繁,所以mysql在启动的时候,就会将所有的权限信息都加载到内存中,并保存在⼏个特定的结构⾥.这就使得每次⼿动修改了相关权限表之后,都需要执⾏flush privileges，通知mysql重新加载mysql的权限信息.当然,如果通过grants,revoke或drop user 命令来修改相关权限，则不需要⼿动执⾏flush privileges命令.3)在主服务器上导出数据库当时的快照,传给从库上.root@10.1.1.45:mysql# mysqldump -uroot -p --single-transaction --flush-logs --master-data --all-databases > all.sql--single-transaction:这个选项能够让innoDB和Falcon数据表在备份过程中保持不变.这⼀做法的关键在于它是在同⼀个事务⾥来导⼊各有关数据表的.mysqldump使⽤repeatable read事务隔离层来⽣成⼀份稳定⼀致的转储⽂件,同时不会阻塞其他客户(对于⾮事务性表,转储过程可能有变化),它不能与--lock-all-tables选项⼀起使⽤.--flush-logs:在导出⼯作开始之前先清空mysql服务器的⽇志⽂件.这样更容易恢复操作,知道在检查点时间之后创建的⼆进制⽇志⽂件是在备份给定数据库之后完成的.结合使⽤--lock-all-tables或--master-data,只有在所有数据表都锁定之后才清除⽇志.这个选项需要具备reload权限. --master-data:使⽤后mysqldump会在dump⽂件中产⽣changer master to命令,⾥⾯记录了dump时刻所对应的详细的log position信息.root@10.1.1.45:mysql# sed -n '1,40p' all.sql-- MySQL dump 10.11---- Host: localhost Database:-- -------------------------------------------------------- Server version 5.0.51a-24+lenny1-log/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;/*!40101 SET NAMES utf8 */;/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;/*!40103 SET TIME_ZONE='+00:00' */;/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;---- Position to start replication or point-in-time recovery from--CHANGE MASTER TO MASTER_LOG_FILE='45.000064', MASTER_LOG_POS=98;---- Current Database: `bbs`--CREATE DATABASE /*!32312 IF NOT EXISTS*/ `bbs` /*!40100 DEFAULT CHARACTER SET latin1 */;USE `bbs`;---- Table structure for table `davehe`--DROP TABLE IF EXISTS `davehe`;SET @saved_cs_client = @@character_set_client;SET character_set_client = utf8;CREATE TABLE `davehe` (2.设置从库1).修改从库fserver-id = 43 #主从可1对多从各id不能相同2)将主库的快照灌⼊从库root@10.1.1.43:tmp# cat all.sql | mysql -uroot -p3)在从库上设置同步.查看从库状态.mysql> change master to master_host='10.1.1.45', master_user='repl',master_password='replpass',master_log_file='45.000064',master_log_pos=98; Query OK, 0 rows affected (0.01 sec)mysql> start slave;Query OK, 0 rows affected (0.00 sec)mysql> show slave status\G;*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 10.1.1.45Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: 45.000064Read_Master_Log_Pos: 98Relay_Log_File: mysqld-relay-bin.000002Relay_Log_Pos: 228Relay_Master_Log_File: 45.000064Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 98Relay_Log_Space: 228Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 01 row in set (0.00 sec)ERROR:No query specified测试OK当然这只是最简单的配置还有很多参数可根据环境需求变化.⽐如replicate-do-db=test 过滤拉主⽇志到从只需要这个库和下⾯的表replicate-wild-do-table=test.davereplicate-wild-do-table=test.davehemysql数据库同步跳过临时错误stop slave;set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; (事务类型,可能需要执⾏⼏次)start slave;stop slave IO_THREAD //此线程把master段的⽇志写到本地start slave IO_THREADstop slave SQL_THREAD //此线程把写到本地的⽇志应⽤于数据库start slave SQL_THREADSlave_IO_Running: No错误由于主库的主机192.168.1.1宕机,再次启来后，从库192.168.71.1连接主库发现报错. Slave_IO_Running: Noroot@192.168.71.1:~# mysql -uroot -p --socket=/opt/mysql/3399/3399.sockEnter password:Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 452723Server version: 5.0.51a-24+lenny2 (Debian)Type 'help;' or '\h' for help. Type '\c' to clear the buffer.mysql> show slave status\G;*************************** 1. row ***************************Slave_IO_State:Master_Host: 192.168.1.1Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: 99.000302Read_Master_Log_Pos: 165112917Relay_Log_File: 3399-relay-bin.000013Relay_Log_Pos: 165113047Relay_Master_Log_File: 99.000302Slave_IO_Running: NoSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB: mysqlReplicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 165112917Relay_Log_Space: 165113047Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: NULL1 row in set (0.00 sec)查看错误⽇志mysql@192.168.71.1:/opt/mysql/3399$ cat 192.168.71.1.err140115 1:51:01 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)140115 1:51:01 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log 140115 1:51:01 [Note] Slave I/O thread exiting, read up to log '99.000302', position 165112917根据错误位置,查找主库上log ‘99.000302' 对应的位置 165112917root@192.168.1.1:mysql.bin# mysqlbinlog 99.000302 > /tmp/testroot@192.168.1.1:mysql# tail -n 10 /tmp/test#140115 0:50:25 server id 1176 end_log_pos 165111351 Query thread_id=111 exec_time=0 error_code=0SET TIMESTAMP=1389718225/*!*/;INSERT INTO user_info_db_86.region_info_table_56 (userid, region, gameflag) VALUES (563625686, 0, 2) ON DUPLICATE KEY UPDATE gameflag = (gameflag | 2)/*!*/; # at 165111351#140115 0:50:25 server id 1176 end_log_pos 165111378 Xid = 17877752COMMIT/*!*/;DELIMITER ;# End of log fileROLLBACK /* added by mysqlbinlog */;/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;结果发现主库上位置最后是165111351 ⽐165112917要⼩. 也就是从库同步找的位置⽐主库要⼤，故同步不成功为什么会这样,这是因为这个在sync_binlog=0的情况，很容易出现。
MySQL主从复制（GTID模式）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⽂件。
GTID模式复制搭建过程中注意事项：主从需要设置如下参数（⼀般直接在配置⽂件/etc/f下直接添加）：a、主库配置：gtid_mode=onenforce_gtid_consistency=onlog_bin=onserver-id=33062200（主从不能相同）binlog_format=rowb、从库配置：gtid_mode=onenforce_gtid_consistency=onlog_slave_updates=1server-id=33062211（主从不能相同）主库上操作：root@db 15:10: [mysql]>create user 'repluser'@'192.168.112.%' identified by 'repluser123';root@db 15:10: [mysql]> grant replication slave on *.* to 'repluser'@'192.168.112.%';主库导出数据库脚本all.sqlmysqldump -uroot -hlocalhost -p --single-transaction --master-data=2 -A >all.sql从库上操作：将主库上导出的all.sql脚本上传到从库，然后导⼊从库mysql -uroot -hlocalhost -p <all.sql如果出现如下错误：ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.则在从库命令⾏下执⾏：reset masterroot@db 15:20: [mysql]> reset master;跟普通模式⼀样，执⾏change master语句，只不过其中的binlog和position换成master_auto_position=1 CHANGE MASTER TOMASTER_HOST='192.168.112.220',MASTER_USER='repluser',MASTER_PASSWORD='repluser123',MASTER_PORT=3306,MASTER_AUTO_POSITION=1;启动slave复制服务start slave;查看主从复制状态：1 root@db 15:23: [mysql]> show slave status\G;2 *************************** 1. row ***************************3 Slave_IO_State: Waiting for master to send event4 Master_Host: 192.168.112.2205 Master_User: repluser6 Master_Port: 33067 Connect_Retry: 608 Master_Log_File: on.0000029 Read_Master_Log_Pos: 253836310 Relay_Log_File: localhost-relay-bin.00000411 Relay_Log_Pos: 203137112 Relay_Master_Log_File: on.00000213 Slave_IO_Running: Yes14 Slave_SQL_Running: Yes15 Replicate_Do_DB:16 Replicate_Ignore_DB:17 Replicate_Do_Table:18 Replicate_Ignore_Table:19 Replicate_Wild_Do_Table:20 Replicate_Wild_Ignore_Table:21 Last_Errno: 022 Last_Error:23 Skip_Counter: 024 Exec_Master_Log_Pos: 253836325 Relay_Log_Space: 203158226 Until_Condition: None27 Until_Log_File:28 Until_Log_Pos: 029 Master_SSL_Allowed: No30 Master_SSL_CA_File:31 Master_SSL_CA_Path:32 Master_SSL_Cert:33 Master_SSL_Cipher:34 Master_SSL_Key:35 Seconds_Behind_Master: 036 Master_SSL_Verify_Server_Cert: No37 Last_IO_Errno: 038 Last_IO_Error:39 Last_SQL_Errno: 040 Last_SQL_Error:41 Replicate_Ignore_Server_Ids:42 Master_Server_Id: 3306022043 Master_UUID: 763c7ef3-5977-11e8-ae7a-000c2936b80f44 Master_Info_File: mysql.slave_master_info45 SQL_Delay: 046 SQL_Remaining_Delay: NULL47 Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates48 Master_Retry_Count: 8640049 Master_Bind:50 Last_IO_Error_Timestamp:51 Last_SQL_Error_Timestamp:52 Master_SSL_Crl:53 Master_SSL_Crlpath:54 Retrieved_Gtid_Set: 763c7ef3-5977-11e8-ae7a-000c2936b80f:1393-692655 Executed_Gtid_Set: 763c7ef3-5977-11e8-ae7a-000c2936b80f:1-692656 Auto_Position: 157 Replicate_Rewrite_DB:58 Channel_Name:59 Master_TLS_Version:601 row in set (0.00 sec)6162 root@db 15:23: [mysql]>View Code由上图可知：Slave_IO_Running: YesSlave_SQL_Running: Yes复制主从复制状态OK，进⼀步查看通过Executed_Gtid_Set查看执⾏过的GTID：root@db 15:38: [mysql]> show master status;+-----------+----------+--------------+------------------+---------------------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+-----------+----------+--------------+------------------+---------------------------------------------+| on.000002 | 3200431 | | | 763c7ef3-5977-11e8-ae7a-000c2936b80f:1-8730 |+-----------+----------+--------------+------------------+---------------------------------------------+1 row in set (0.00 sec)root@db 15:38: [mysql]>在MySQL5.7版本之后，gtid_executed这个值持久化了，在MySQL库下新增了⼀张表gtid_executedroot@db 15:38: [mysql]> desc gtid_executed;+----------------+------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+----------------+------------+------+-----+---------+-------+| source_uuid | char(36) | NO | PRI | NULL | || interval_start | bigint(20) | NO | PRI | NULL | || interval_end | bigint(20) | NO | | NULL | |+----------------+------------+------+-----+---------+-------+3 rows in set (0.00 sec)root@db 15:40: [mysql]>root@db 15:41: [mysql]> select * from gtid_executed;+--------------------------------------+----------------+--------------+| source_uuid | interval_start | interval_end |+--------------------------------------+----------------+--------------+| 763c7ef3-5977-11e8-ae7a-000c2936b80f | 1 | 6 |+--------------------------------------+----------------+--------------+1 row in set (0.00 sec)root@db 15:42: [mysql]>该表会记录执⾏的GTID集合信息，因为有了该表，就不⽤再像MySQL 5.6版本时，必须开启log_slave_updates参数，从库才可以进⾏赋值。
MySQL主从复制的常见问题与解决方案MySQL主从复制是一种常见的数据库复制技术，它可以将一个数据库（主库）的变更同步到其他多个数据库（从库），使得数据的读写操作可以同时在多个数据库中进行。
这种技术在分布式系统中广泛应用，能够提高数据库的性能和可用性。
然而，在实际应用中，MySQL主从复制也会遇到一些常见的问题。
本文将重点讨论这些问题并提供解决方案。
一、延迟复制问题MySQL主从复制的一个常见问题是延迟复制。
由于主库和从库之间的网络延迟或从库的负载过重，导致从库上的数据更新与主库有一定的时间差。
这种延迟可能会导致数据不一致问题，严重影响业务的正确性和稳定性。
解决方案：1. 优化网络连接：检查主从库之间的网络连接，并确保网络带宽足够大，延迟尽可能小。
2. 优化从库性能：如果从库的负载过重，可以考虑增加从库的内存和CPU资源，或者升级硬件设备。
3. 使用并行复制：MySQL 5.6及以上版本支持并行复制，在从库开启并行复制模式，可以提高复制的效率和减少延迟。
二、主从数据不一致问题MySQL主从复制过程中，可能会遇到数据不一致的问题，即从库上的数据与主库不一致。
常见的原因包括：网络故障，主库宕机，复制中断等。
这种问题往往需要及时解决，以避免数据丢失和业务异常。
解决方案：1. 检查主从状态：使用MySQL的命令SHOW SLAVE STATUS检查主从状态，确保主从复制处于正常运行状态。
2. 检查复制延迟：通过比较主库和从库的binlog位置，判断是否存在复制延迟。
如果延迟较大，可以考虑重启从库，重新建立主从复制连接。
3. 检查复制中断原因：如果发现复制中断，可以通过查看错误日志或者SHOW SLAVE STATUS输出，找到中断原因并进行相应的处理。
常见的中断原因有：主库宕机、从库空间不足、主库binlog日志满等。
4. 数据修复：如果数据不一致，可以通过手动修复或者重新同步数据来解决。
可以使用工具如pt-table-checksum和pt-table-sync进行数据校验和修复。
mysql主从同步原理及错误解决MySQL主从复制是一种常见的数据库备份和灾难恢复机制。
它允许将一个MySQL数据库（主服务器）的更改复制到一个或多个备份数据库（从服务器）上。
主从复制的原理是主服务器将更改记录到二进制日志（bin-log），从服务器通过读取主服务器的二进制日志并应用这些更改来保持与主服务器的同步。
主从同步的原理可以分为以下几个步骤：1. 主服务器将更改记录到二进制日志（bin-log）：当在主服务器上进行了增、删、改等修改操作时，主服务器将生成一条对应的二进制日志记录，并将其写入到二进制日志文件中。
2.从服务器连接到主服务器：从服务器与主服务器建立连接，并请求从指定位置开始读取二进制日志。
3.主服务器发送二进制日志给从服务器：主服务器将从请求的位置开始的二进制日志传送给从服务器。
4. 从服务器将二进制日志写入到中继日志（relay-log）：从服务器将接收到的二进制日志写入到中继日志文件中。
5.从服务器读取中继日志并应用更改：从服务器读取中继日志中的更改，并将其应用到从服务器的数据库中，以实现与主服务器的同步。
6.从服务器发送确认信息给主服务器：从服务器将应用成功的二进制日志位置信息发送给主服务器，用于下次同步时继续读取。
除了主从同步的原理，还有一些常见的错误可能会影响主从同步的正确运行。
以下是几种常见的错误及其解决方法：1.主从服务器时间不同步：主从服务器的时间差异会导致二进制日志的生成顺序错误，进而导致主从同步错误。
解决方法是确保主从服务器时间一致，可以使用NTP等工具进行时间同步。
2.主服务器宕机或网络故障：当主服务器宕机或网络故障时，从服务器无法继续从主服务器获取二进制日志，导致主从同步中断。
解决方法是在主服务器出现故障后，将一个从服务器提升为主服务器，然后重新配置其他从服务器与新的主服务器建立连接。
3.数据库表结构改变：如果在主服务器上修改了表结构，而从服务器没有同步相应的修改，就会导致主从同步错误。
如何使用MySQL进行数据同步和复制数据库是现代应用开发的核心组成部分，而MySQL是最受欢迎的数据库之一。
在实际应用中，数据同步和复制是非常重要的需求，它可以保证数据的一致性和高可用性。
本文将介绍如何使用MySQL进行数据同步和复制的方法和技巧。
一、数据同步的基本概念和原理数据同步是指将一个数据库中的数据更新到另一个数据库中，以保证数据的一致性。
在实际应用中，数据同步可以采用多种方式实现，如主从复制、双向同步、多主一从等。
主从复制是最常用的数据同步方式之一。
它的原理是通过二进制日志（binary log）记录主数据库中的数据变更操作，并将这些操作记录传递给从数据库，从数据库根据这些操作重新执行更新操作，从而保持主数据库和从数据库的数据一致。
二、使用MySQL进行数据同步的方法和技巧1. 配置主数据库首先，在主数据库端需要进行一些配置工作。
打开主数据库的f配置文件，将以下行加入其中：```server-id = 1log-bin = mysql-binbinlog-do-db = your_database_name```其中，server-id是服务器的唯一标识，log-bin指定二进制日志的存储位置和日志文件名，binlog-do-db指定要同步的数据库名。
配置完成后，重启MySQL服务器。
2. 配置从数据库接下来，在从数据库端进行配置。
同样地，在从数据库的f配置文件中加入以下行：```server-id = 2relay-log = mysql-relay-binlog-slave-updates = 1```其中，server-id是服务器的唯一标识，relay-log指定中继日志的存储位置和日志文件名，log-slave-updates指定从数据库是否记录二进制日志。
配置完成后，重启MySQL服务器。
3. 启动数据同步配置完成后，在主数据库端执行以下命令启动数据同步：```FLUSH TABLES WITH READ LOCK;SHOW MASTER STATUS;```记录下SHOW MASTER STATUS命令返回的结果，需要在后续的步骤中使用。
线上MYSQL同步报错故障处理⽅法总结（必看篇）前⾔在发⽣故障切换后，经常遇到的问题就是同步报错，数据库很⼩的时候，dump完再导⼊很简单就处理好了，但线上的数据库都150G-200G，如果⽤单纯的这种⽅法，成本太⾼，故经过⼀段时间的摸索，总结了⼏种处理⽅法。
⽣产环境架构图⽬前现⽹的架构，保存着两份数据，通过异步复制做的⾼可⽤集群，两台机器提供对外服务。
在发⽣故障时，切换到slave 上，并将其变成master，坏掉的机器反向同步新的master，在处理故障时，遇到最多的就是主从报错。
下⾯是我收录下来的报错信息。
常见错误最常见的3种情况这3种情况是在HA切换时，由于是异步复制，且sync_binlog=0，会造成⼀⼩部分binlog没接收完导致同步报错。
第⼀种：在master上删除⼀条记录，⽽slave上找不到。
Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1;Can't find record in 't1',Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;the event's master log mysql-bin.000006, end_log_pos 254第⼆种：主键重复。
在slave已经有该记录，⼜在master上插⼊了同⼀条记录。
Last_SQL_Error: Could not execute Write_rows event on table hcy.t1;Duplicate entry '2' for key 'PRIMARY',Error_code: 1062;handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924第三种：在master上更新⼀条记录，⽽slave上找不到，丢失了数据。
