复制概述

Mysql内建的复制性能是构建大型，高性能应用程序的根底。将Mysql的数据分布到多个零碎下来，这种散布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并从新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并保护文件的一个索引以跟踪日志循环。这些日志能够记录发送到从服务器的更新。当一个从服务器连贯主服务器时，它告诉主服务器从服务器在日志中读取的最初一次胜利更新的地位。从服务器接管从那时起产生的任何更新，而后封闭并期待主服务器告诉新的更新。

请留神当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以防止用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的抵触。

mysql反对的复制类型：

  • 基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采纳基于语句的复制，效率比拟高。一旦发现没法准确复制时，   会主动选着基于行的复制。
  • 基于行的复制：把扭转的内容复制过来，而不是把命令在从服务器上执行一遍. 从mysql5.0开始反对
  • 混合类型的复制: 默认采纳基于语句的复制，一旦发现基于语句的无奈准确的复制时，就会采纳基于行的复制。

复制解决的问题

MySQL复制技术有以下一些特点：

  • 数据分布 (Data distribution )
  • 负载平衡(load balancing)
  • 备份(Backups)
  • 高可用性和容错行 High availability and failover

复制如何工作

整体上来说，复制有3个步骤：

  • master将扭转记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
  • slave将master的binary log events拷贝到它的中继日志(relay log)；
  • slave重做中继日志中的事件，将扭转反映它本人的数据。

下图形容了复制的过程：

  • 该过程的第一局部就是master记录二进制日志。在每个事务更新数据实现之前，master在二日志记录这些扭转。MySQL将事务串行的写入二进制日志，即便事务中的语句都是穿插执行的。在事件写入二进制日志实现后，master告诉存储引擎提交事务。
  • 下一步就是slave将master的binary log拷贝到它本人的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上关上一个一般的连贯，而后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果曾经跟上master，它会睡眠并期待master产生新的事件。I/O线程将这些事件写入中继日志。
  • SQL slave thread（SQL从线程）解决该过程的最初一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数据统一。只有该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
  • 此外，在master中也有一个工作线程：和其它MySQL的连贯一样，slave在master中关上一个连贯也会使得master开始一个线程。复制过程有一个很重要的限度——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

主从复制配置

有两台MySQL数据库服务器Master和slave，Master为主服务器，slave为从服务器，初始状态时，Master和slave中的数据信息雷同，当Master中的数据发生变化时，slave也跟着产生相应的变动，使得master和slave的数据信息同步，达到备份的目标。

要点：负责在主、从服务器传输各种批改动作的媒介是主服务器的二进制变更日志，这个日志记录着须要传输给从服务器的各种批改动作。因而，主服务器必须激活二进制日志性能。从服务器必须具备足以让它连贯主服务器并申请主服务器把二进制变更日志传输给它的权限。

环境：

  • Master和slave的MySQL数据库版本同为5.0.18
  • IP地址：10.100.0.100

创立复制帐号

1、在Master的数据库中建设一个备份帐户：每个slave应用规范的MySQL用户名和明码连贯master。进行复制操作的用户会授予REPLICATION SLAVE权限。用户名的明码都会存储在文本文件master.info中

命令如下：

mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@’10.100.0.200’ IDENTIFIED BY ‘1234’;

建设一个帐户backup，并且只能容许从10.100.0.200这个地址上来登陆，明码是1234。

如果因为mysql版本新旧明码算法不同，能够设置：

set password for 'backup'@'10.100.0.200'=old_password('1234')

拷贝数据:（如果是你齐全新装置mysql主从服务器，这个一步就不须要。因为新装置的master和slave有雷同的数据）

关停Master服务器，将Master中的数据拷贝到B服务器中，使得Master和slave中的数据同步，并且确保在全副设置操作完结前，禁止在Master和slave服务器中进行写操作，使得两数据库中的数据肯定要雷同！

配置master

接下来对master进行配置，包含关上二进制日志，指定惟一的servr ID。例如，在配置文件退出如下值：

server-id=1log-bin=mysql-binserver-id：为主服务器A的ID值log-bin：二进制变更日值

重启master，运行SHOW MASTER STATUS，输入如下：

配置slave

Slave的配置与master相似，你同样须要重启slave的MySQL。如下：

log_bin           = mysql-binserver_id         = 2relay_log         = mysql-relay-binlog_slave_updates = 1read_only         = 1#server_id：是必须的，而且惟一。

log_bin：slave没有必要开启二进制日志bin_log，然而在一些状况下，必须设置，例如，如果slave为其它slave的master，必须设置bin_log。在这里，咱们开启了二进制日志，而且显示的命名(默认名称为hostname，然而，如果hostname扭转则会呈现问题)。

relay_log：配置中继日志，log_slave_updates示意slave将复制事件写进本人的二进制日志(前面会看到它的用途)。有些人开启了slave的二进制日志，却没有设置log_slave_updates，而后查看slave的数据是否扭转，这是一种谬误的配置。

read_only：尽量应用read_only，它避免扭转数据(除了非凡的线程)。然而，read_only并是很实用，特地是那些须要在slave上创立表的利用。

启动slave

接下来就是让slave连贯master，并开始重做master二进制日志中的事件。你不应该用配置文件进行该操作，而应该应用CHANGE MASTER TO语句，该语句能够齐全取代对配置文件的批改，而且它能够为slave指定不同的master，而不须要进行服务器。如下：

mysql> CHANGE MASTER TO MASTER_HOST='server1',-> MASTER_USER='repl',-> MASTER_PASSWORD='p4ssword',-> MASTER_LOG_FILE='mysql-bin.000001',-> MASTER_LOG_POS=0;

MASTER_LOG_POS的值为0，因为它是日志的开始地位。

你能够用SHOW SLAVE STATUS语句查看slave的设置是否正确：

mysql> SHOW SLAVE STATUSG*************************** 1. row ***************************Slave_IO_State:Master_Host: server1Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000001Read_Master_Log_Pos: 4Relay_Log_File: mysql-relay-bin.000001Relay_Log_Pos: 4Relay_Master_Log_File: mysql-bin.000001Slave_IO_Running: NoSlave_SQL_Running: No...omitted...Seconds_Behind_Master: NULL

Slave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No，表明slave还没有开始复制过程。日志的地位为4而不是0，这是因为0只是日志文件的开始地位，并不是日志地位。实际上，MySQL晓得的第一个事件的地位是4。

为了开始复制，你能够运行：

mysql> START SLAVE;

运行SHOW SLAVE STATUS查看输入后果：

mysql> SHOW SLAVE STATUSG*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: server1Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000001Read_Master_Log_Pos: 164Relay_Log_File: mysql-relay-bin.000001Relay_Log_Pos: 164Relay_Master_Log_File: mysql-bin.000001Slave_IO_Running: YesSlave_SQL_Running: Yes...omitted...Seconds_Behind_Master: 0

在这里次要是看:

  • Slave_IO_Running=Yes
  • Slave_SQL_Running=Yes

slave的I/O和SQL线程都曾经开始运行，而且Seconds_Behind_Master不再是NULL。日志的地位减少了，意味着一些事件被获取并执行了。如果你在master上进行批改，你能够在slave上看到各种日志文件的地位的变动，同样，你也能够看到数据库中数据的变动。

你可查看master和slave上线程的状态。在master上，你能够看到slave的I/O线程创立的连贯：

在master上输出show processlistG;

mysql> show processlist G*************************** 1. row ***************************Id: 1User: rootHost: localhost:2096db: testCommand: QueryTime: 0State: NULLInfo: show processlist*************************** 2. row ***************************Id: 2User: replHost: localhost:2144db: NULLCommand: Binlog DumpTime: 1838State: Has sent all binlog to slave; waiting for binlog to be updatedInfo: NULL2 rows in set (0.00 sec)

行2为解决slave的I/O线程的连贯。

在slave服务器上运行该语句：

mysql> show processlist G*************************** 1. row ***************************Id: 1User: system userHost:db: NULLCommand: ConnectTime: 2291State: Waiting for master to send eventInfo: NULL*************************** 2. row ***************************Id: 2User: system userHost:db: NULLCommand: ConnectTime: 1852State: Has read all relay log; waiting for the slave I/O thread to update itInfo: NULL*************************** 3. row ***************************Id: 5User: rootHost: localhost:2152db: testCommand: QueryTime: 0State: NULLInfo: show processlist3 rows in set (0.00 sec)

行1为I/O线程状态，行2为SQL线程状态。

增加新slave服务器

如果master曾经运行很久了，想对新装置的slave进行数据同步，甚至它没有master的数据。此时，有几种办法能够使slave从另一个服务开始，例如，从master拷贝数据，从另一个slave克隆，从最近的备份开始一个slave。Slave与master同步时，须要三样货色：

  • (1)master的某个时刻的数据快照；
  • (2)master以后的日志文件、以及生成快照时的字节偏移。这两个值能够叫做日志文件坐标(log file coordinate)，因为它们确定了一个二进制日志的地位，你能够用SHOW MASTER STATUS命令找到日志文件的坐标；
  • (3)master的二进制日志文件。

能够通过以下几中办法来克隆一个slave：

  • (1)冷拷贝(cold copy)
  • 进行master，将master的文件拷贝到slave；而后重启master。毛病很显著。
  • (2)热拷贝(warm copy)
  • 如果你仅应用MyISAM表，你能够应用mysqlhotcopy拷贝，即便服务器正在运行。
  • (3)应用mysqldump
  • <1>锁表：如果你还没有锁表，你应该对表加锁，避免其它连贯批改数据库，否则，你失去的数据能够是不统一的。如下：
  • 应用mysqldump来失去一个数据快照可分为以下几步：
mysql> FLUSH TABLES WITH READ LOCK;
  • <2>在另一个连贯用mysqldump创立一个你想进行复制的数据库的转储：
shell> mysqldump --all-databases --lock-all-tables >dbdump.db
  • <3>对表开释锁。
mysql> UNLOCK TABLES;

深刻理解复制

曾经探讨了对于复制的一些根本货色，上面深刻讨论一下复制。

基于语句的复制(Statement-Based Replication)

MySQL 5.0及之前的版本仅反对基于语句的复制（也叫做逻辑复制，logical replication），这在数据库并不常见。master记录下扭转数据的查问，而后，slave从中继日志中读取事件，并执行它，这些SQL语句与master执行的语句一样。

这种形式的长处就是实现简略。此外，基于语句的复制的二进制日志能够很好的进行压缩，而且日志的数据量也较小，占用带宽少——例如，一个更新GB的数据的查问仅须要几十个字节的二进制日志。而mysqlbinlog对于基于语句的日志解决非常不便。

然而，基于语句的复制并不是像它看起来那么简略，因为一些查问语句依赖于master的特定条件，例如，master与slave可能有不同的工夫。所以，MySQL的二进制日志的格局不仅仅是查问语句，还包含一些元数据信息，例如，以后的工夫戳。即使如此，还是有一些语句，比方，CURRENT USER函数，不能正确的进行复制。此外，存储过程和触发器也是一个问题。

另外一个问题就是基于语句的复制必须是串行化的。这要求大量非凡的代码，配置，例如InnoDB的next-key锁等。并不是所有的存储引擎都反对基于语句的复制。

基于记录的复制(Row-Based Replication)

MySQL减少基于记录的复制，在二进制日志中记录下理论数据的扭转，这与其它一些DBMS的实现形式相似。这种形式有长处，也有毛病。长处就是能够对任何语句都能正确工作，一些语句的效率更高。次要的毛病就是二进制日志可能会很大，而且不直观，所以，你不能应用mysqlbinlog来查看二进制日志。

对于一些语句，基于记录的复制可能更无效的工作，如：

mysql> INSERT INTO summary_table(col1, col2, sum_col3)    -> SELECT col1, col2, sum(col3)    -> FROM enormous_table    -> GROUP BY col1, col2;

假如，只有三种惟一的col1和col2的组合，然而，该查问会扫描原表的许多行，却仅返回三条记录。此时，基于记录的复制效率更高。

另一方面，上面的语句，基于语句的复制更无效：

 mysql> UPDATE enormous_table SET col1 = 0;

此时应用基于记录的复制代价会十分高。因为两种形式不能对所有状况都能很好的解决，所以，MySQL 5.1反对在基于语句的复制和基于记录的复制之前动静替换。你能够通过设置session变量binlog_format来进行管制。

复制相干的文件

除了二进制日志和中继日志文件外，还有其它一些与复制相干的文件。如下：

  • (1)mysql-bin.index

服务器一旦开启二进制日志，会产生一个与二日志文件同名，然而以.index结尾的文件。它用于跟踪磁盘上存在哪些二进制日志文件。MySQL用它来定位二进制日志文件。它的内容如下(我的机器上)：

  • (2)mysql-relay-bin.index

该文件的性能与mysql-bin.index相似，然而它是针对中继日志，而不是二进制日志。内容如下：

.mysql-02-relay-bin.000017.mysql-02-relay-bin.000018
  • (3)master.info

保留master的相干信息。不要删除它，否则，slave重启后不能连贯master。内容如下(我的机器上)：I/O线程更新master.info文件，内容如下(我的机器上)：

.mysql-02-relay-bin.000019254mysql-01-bin.000010286052813
  • (4)relay-log.info

蕴含slave中以后二进制日志和中继日志的信息。

发送复制事件到其它slave

当设置log_slave_updates时，你能够让slave表演其它slave的master。此时，slave把SQL线程执行的事件写进行本人的二进制日志(binary log)，而后，它的slave能够获取这些事件并执行它。如下：

复制过滤(Replication Filters)

复制过滤能够让你只复制服务器中的一部分数据，有两种复制过滤：在master上过滤二进制日志中的事件；在slave上过滤中继日志中的事件。如下：

复制的罕用拓扑构造

复制的体系结构有以下一些根本准则：

  • (1)每个slave只能有一个master；
  • (2)每个slave只能有一个惟一的服务器ID；
  • (3)每个master能够有很多slave；
  • (4)如果你设置log_slave_updates，slave能够是其它slave的master，从而扩散master的更新。

MySQL不反对多主服务器复制(Multimaster Replication)——即一个slave能够有多个master。然而，通过一些简略的组合，咱们却能够建设灵便而弱小的复制体系结构。

繁多master和多slave

由一个master和一个slave组成复制零碎是最简略的状况。Slave之间并不互相通信，只能与master进行通信。

在理论利用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式，次要用于读压力比拟大的利用的数据库端便宜扩大解决方案。因为只有Master和Slave的压力不是太大（尤其是Slave端压力）的话，异步复制的延时个别都很少很少。尤其是自从Slave端的复制形式改成两个线程解决之后，更是减小了Slave端的延时问题。而带来的效益是，对于数据实时性要求不是特地Critical的利用，只须要通过便宜的pcserver来扩大Slave的数量，将读压力扩散到多台Slave的机器下面，即可通过扩散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库利用零碎中的读压力还是要比写压力大很多。这在很大水平上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在应用相似计划解决数据库瓶颈。

如下：如果写操作较少，而读操作很时，能够采取这种构造。你能够将读操作散布到其它的slave，从而减小master的压力。然而，当slave减少到肯定数量时，slave对master的负载以及网络带宽都会成为一个重大的问题。

这种构造尽管简略，然而，它却非常灵活，足够满足大多数利用需要。一些倡议：

  • (1)不同的slave表演不同的作用(例如应用不同的索引，或者不同的存储引擎)；
  • (2)用一个slave作为备用master，只进行复制；
  • (3)用一个近程的slave，用于劫难复原；

大家应该都比较清楚，从一个Master节点能够复制出多个Slave节点，可能有人会想，那一个Slave节点是否能够从多个Master节点下面进行复制呢？至多在目前来看，MySQL是做不到的，当前是否会反对就不分明了。

MySQL不反对一个Slave节点从多个Master节点来进行复制的架构，次要是为了防止抵触的问题，避免多个数据源之间的数据呈现抵触，而造成最初数据的不一致性。不过据说曾经有人开发了相干的patch，让MySQL反对一个Slave节点从多个Master结点作为数据源来进行复制，这也正是MySQL开源的性质所带来的益处。

被动模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master复制的两台服务器，既是master，又是另一台服务器的slave。这样，任何一方所做的变更，都会通过复制利用到另外一方的数据库中。

可能有些读者敌人会有一个放心，这样搭建复制环境之后，难道不会造成两台MySQL之间的循环复制么？实际上MySQL本人早就想到了这一点，所以在MySQL的BinaryLog中记录了以后MySQL的server-id，而且这个参数也是咱们搭建MySQLReplication的时候必须明确指定，而且Master和Slave的server-id参数值比须要不统一能力使MySQLReplication搭建胜利。

一旦有了server-id的值之后，MySQL就很容易判断某个变更是从哪一个MySQLServer最后产生的，所以就很容易避免出现循环复制的状况。而且，如果咱们不关上记录Slave的BinaryLog的选项（--log-slave-update）的时候，MySQL基本就不会记录复制过程中的变更到BinaryLog中，就更不必放心可能会呈现循环复制的情景了。如图：被动的Master-Master复制有一些非凡的用途。例如，天文上散布的两个局部都须要本人的可写的数据正本。这种构造最大的问题就是更新抵触。假如一个表只有一行(一列)的数据，其值为1，如果两个服务器别离同时执行如下语句：

#在第一个服务器上执行：mysql> UPDATE tbl SET col=col + 1;#在第二个服务器上执行：mysql> UPDATE tbl SET col=col * 2;

那么后果是多少呢？一台服务器是4，另一个服务器是3，然而，这并不会产生谬误。

实际上，MySQL并不反对其它一些DBMS反对的多主服务器复制(Multimaster Replication)，这是MySQL的复制性能很大的一个限度(多主服务器的难点在于解决更新抵触)，然而，如果你切实有这种需要，你能够采纳MySQL Cluster，以及将Cluster和Replication联合起来，能够建设弱小的高性能的数据库平台。然而，能够通过其它一些形式来模仿这种多主服务器的复制。

被动-被动模式的Master-Master(Master-Master in Active-Passive Mode)这是master-master构造变动而来的，它防止了M-M的毛病，实际上，这是一种具备容错和高可用性的零碎。它的不同点在于其中一个服务只能进行只读操作。如图：

级联复制架构Master –Slaves - Slaves

在有些利用场景中，可能读写压力差异比拟大，读压力特地的大，一个Master可能须要上10台甚至更多的Slave才可能撑持注读的压力。这时候，Master就会比拟吃力了，因为仅仅连上来的SlaveIO线程就比拟多了，这样写的压力略微大一点的时候，Master端因为复制就会耗费较多的资源，很容易造成复制的延时。

遇到这种状况如何解决呢？这时候咱们就能够利用MySQL能够在Slave端记录复制所产生变更的BinaryLog信息的性能，也就是关上—log-slave-update选项。而后，通过二级（或者是更多级别）复制来缩小Master端因为复制所带来的压力。也就是说，咱们首先通过多数几台MySQL从Master来进行复制，这几台机器咱们权且称之为第一级Slave集群，而后其余的Slave再从第一级Slave集群来进行复制。从第一级Slave进行复制的Slave，我称之为第二级Slave集群。如果有须要，咱们能够持续往下减少更多层次的复制。这样，咱们很容易就管制了每一台MySQL下面所从属Slave的数量。这种架构我称之为Master-Slaves-Slaves架构

这种多层级联复制的架构，很容易就解决了Master端因为从属Slave太多而成为瓶颈的危险。下图展现了多层级联复制的Replication架构。当然，如果条件容许，我更偏向于倡议大家通过拆分成多个Replication集群来解决

上述瓶颈问题。毕竟Slave并没有缩小写的量，所有Slave实际上依然还是利用了所有的数据变更操作，没有缩小任何写IO。相同，Slave越多，整个集群的写IO总量也就会越多，咱们没有非常明显的感觉，仅仅只是因为扩散到了多台机器下面，所以不是很容易体现进去。

此外，减少复制的级联档次，同一个变更传到最底层的Slave所须要通过的MySQL也会更多，同样可能造成延时较长的危险。

而如果咱们通过分拆集群的形式来解决的话，可能就会要好很多了，当然，分拆集群也须要更简单的技术和更简单的利用零碎架构。

带从服务器的Master-Master构造(Master-Master with Slaves) 这种构造的长处就是提供了冗余。在天文上散布的复制构造，它不存在繁多节点故障问题，而且还能够将读密集型的申请放到slave上。级联复制在肯定水平下面的确解决了Master因为所从属的Slave过多而成为瓶颈的问题，然而他并不能解决人工保护和出现异常须要切换后可能存在从新搭建Replication的问题。这样就很天然的引申出了DualMaster与级联复制联合的Replication架构，我称之为Master-Master-Slaves架构

和Master-Slaves-Slaves架构相比，区别仅仅只是将第一级Slave集群换成了一台独自的Master，作为备用Master，而后再从这个备用的Master进行复制到一个Slave集群。

这种DualMaster与级联复制联合的架构，最大的益处就是既能够防止主Master的写入操作不会受到Slave集群的复制所带来的影响，同时主Master须要切换的时候也基本上不会呈现重搭Replication的状况。然而，这个架构也有一个弊病，那就是备用的Master有可能成为瓶颈，因为如果前面的Slave集群比拟大的话，备用Master可能会因为过多的SlaveIO线程申请而成为瓶颈。

当然，该备用Master不提供任何的读服务的时候，瓶颈呈现的可能性并不是特地高，如果呈现瓶颈，也能够在备用Master前面再次进行级联复制，架设多层Slave集群。当然，级联复制的级别越多，Slave集群可能呈现的数据延时也会更为显著，所以思考应用多层级联复制之前，也须要评估数据延时对利用零碎的影响。

复制的常见问题

谬误一：change master导致的：

Last_IO_Error: error connecting to master 'repl1@IP:3306' - retry-time: 60  retries

谬误二：在没有解锁的状况下进行slave过程：

mysql> stop slave;ERROR 1192 (HY000): Can't execute the given command because you have active locked tables or an active transaction

谬误三：在没有进行slave过程的状况下change master

mysql> change master to master_host=‘IP', master_user='USER', master_password='PASSWD', master_log_file='mysql-bin.000001',master_log_pos=106;ERROR 1198 (HY000): This operation cannot be performed with a running slave; run STOP SLAVE first

谬误四：A B的server-id雷同：

Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used onslave but this does not always make sense; please check the manual before using it). #查看server-idmysql> show variables like 'server_id'; #手动批改server-idmysql> set global server_id=2; #此处的数值和my.cnf里设置的一样就行 mysql> slave start;

谬误五：change master之后，查看slave的状态，发现slave_IO_running 仍为NO

须要留神的是，上述几个谬误做完操作之后要重启mysql过程，slave_IO_running 变为Yes

谬误六：MySQL主从同步异样Client requested master to start replication from position > file size

字面了解：从库的读取binlog的地位大于主库以后binglog的值

这个别是主库重启导致的问题，主库从参数sync_binlog默认为1000，即主库的数据是先缓存到1000条后对立fsync到磁盘的binlog文件中。当主库重启的时候，从库间接读取主库接着之前的位点从新拉binlog，然而主库因为没有fsync最初的binlog，所以会返回1236的谬误。

失常倡议配置sync_binlog=1 也就是每个事务都立刻写入到binlog文件中。

  • 1、在从库查看slave状态:

偏移量为4063315

  • 2、在主库查看mysql-bin.001574的偏移量地位
mysqlbinlog mysql-bin.001574 >  ./mysql-bin.001574.baktail -10 ./mysql-bin.001574.bak

mysql-bin.001574文件最初几行 发现最初偏移量是4059237，从库偏移量的4063315远大主库的偏移量4059237，也就是参数sync_binlog=1000导致的。

  • 3、从新设置salve
mysql> stop slave;mysql> change master to master_log_file='mysql-bin.001574' ,master_log_pos=4059237;mysql> start slave;

谬误8：数据同步异常情况

  • 第一种：在master上删除一条记录，而slave上找不到。
Last_Error: Could not execute Delete_rows event on table market_edu.tl_player_task; Can't find record in 'tl_player_task', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.002094, end_log_pos 286434186

解决办法：因为master要删除一条记录，而slave上找不到故报错，这种状况主上都将其删除了，那么从机能够间接跳过。可用命令：

stop slave;   set global sql_slave_skip_counter=1;    start slave;
  • 第二种：主键反复。在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

解决办法：在slave删除反复的主键.

  • 第三种：在master上更新一条记录，而slave上找不到，失落了数据。
Last_SQL_Error: Could not execute Update_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.000010, end_log_pos 263

解决办法：把失落的数据在slave上填补，而后跳过报错即可。

insert into t1 values (2,'BTV');stop slave ;set global sql_slave_skip_counter=1;start slave;

起源：https://guisu.blog.csdn.net/a...