高性能Mysql主从架构的复制原理及设置详解

开心每二天

原标题：高性能 Mysql 主从架构的复制原理及设置详解

泉源：http://reurl.cc/WELbR5

泉源：http://reurl.cc/WELbR5

复制概述

Mysql内建的复制功能是构建大型，高性能应用步伐的底子。将Mysql的数据分布到多个体系上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到别的主机（slaves）上，并重新实行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个别的服务器充当从服务器。主服务器将更新写入二进制日记文件，并维护文件的一个索引以跟踪日记循环。这些日记可以记载发送到从服务器的更新。当一个从服务器毗连主服务器时，它关照主服务器从服务器在日记中读取的末了一次乐成更新的位置。从服务器吸收从当时起发生的任何更新，然后封锁并等候主服务器关照新的更新。

请留意当你举行复制时，全部对复制中的表的更新必须在主服务器上举行。否则，你必须要警惕，以制止用户对主服务器上的表举行的更新与对从服务器上的表所举行的更新之间的辩论。

mysql支持的复制范例：

• 基于语句的复制：在主服务器上实行的SQL语句，在从服务器上实行同样的语句。MySQL默认接纳基于语句的复制，服从比力高。一旦发现没法准确复制时， 会主动选着基于行的复制。

• 基于行的复制：把改变的内容复制已往，而不是把下令在从服务器上实行一遍. 从mysql5.0开始支持

• 混淆范例的复制: 默认接纳基于语句的复制，一旦发现基于语句的无法准确的复制时，就会接纳基于行的复制。

基于语句的复制：在主服务器上实行的SQL语句，在从服务器上实行同样的语句。MySQL默认接纳基于语句的复制，服从比力高。一旦发现没法准确复制时， 会主动选着基于行的复制。

基于行的复制：把改变的内容复制已往，而不是把下令在从服务器上实行一遍. 从mysql5.0开始支持

混淆范例的复制: 默认接纳基于语句的复制，一旦发现基于语句的无法准确的复制时，就会接纳基于行的复制。

复制办理的题目

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

• 数据分布 (Data distribution )

• 负载均衡(load balancing)

• 备份(Backups)

• 高可用性和容错行 High availability and failover

睁开全文

数据分布 (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将改变记载到二进制日记(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上并行操纵。

该过程的第一部门就是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

Master和slave的MySQL数据库版本同为5.0.18

IP地点：10.100.0.100

创建复制帐号

1、在Master的数据库中创建一个备份帐户：每个slave利用尺度的MySQL用户名和暗码毗连master。举行复制操纵的用户会授予REPLICATION SLAVE权限。用户名的暗码都会存储在文本文件master.info中

下令如下：

mysql > GRANTREPLICATIONSLAVE,RELOAD,SUPER ON*.*

TObackup@’ 10.100.0.200’

IDENTIFIEDBY‘ 1234’;

创建一个帐户backup，而且只能答应从10.100.0.200这个地点上来登岸，暗码是1234。

假如由于mysql版本新旧暗码算法差别，可以设置：

setpassword 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=1

log-bin=mysql-bin

server-id：为主服务器A的ID值

log-bin：二进制变动日值

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

设置slave

Slave的设置与master雷同，你同样必要重启slave的MySQL。如下：

log_bin = mysql-bin

server_id = 2

relay_log = mysql-relay-bin

log_slave_updates = 1

read_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> CHANGEMASTERTOMASTER_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> SHOWSLAVESTATUSG

*************************** 1.row***************************

Slave_IO_State:

Master_Host: server1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql- bin.000001

Read_Master_Log_Pos: 4

Relay_Log_File: mysql-relay- bin.000001

Relay_Log_Pos: 4

Relay_Master_Log_File: mysql- bin.000001

Slave_IO_Running: No

Slave_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> STARTSLAVE;

运行SHOW SLAVE STATUS检察输出效果：

mysql> SHOWSLAVESTATUSG

*************************** 1.row***************************

Slave_IO_State: Waiting formastertosend event

Master_Host: server1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql- bin.000001

Read_Master_Log_Pos: 164

Relay_Log_File: mysql-relay- bin.000001

Relay_Log_Pos: 164

Relay_Master_Log_File: mysql- bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

...omitted...

Seconds_Behind_Master: 0

在这里重要是看:

• Slave_IO_Running=Yes

• Slave_SQL_Running=Yes

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> showprocesslistG

*************************** 1.row***************************

Id: 1

User: root

Host: localhost: 2096

db: test

Command: Query

Time: 0

State: NULL

Info: showprocesslist

*************************** 2.row***************************

Id: 2

User: repl

Host: localhost: 2144

db: NULL

Command: BinlogDump

Time: 1838

State: Has sent allbinlogtoslave; waiting for binlog to be updated

Info: NULL

2 rows in set( 0.00sec)

行2为处置惩罚slave的I/O线程的毗连。

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

mysql> showprocesslistG

*************************** 1.row***************************

Id: 1

User: systemuser

Host:

db: NULL

Command: Connect

Time: 2291

State: Waiting formastertosend event

Info: NULL

*************************** 2.row***************************

Id: 2

User: systemuser

Host:

db: NULL

Command: Connect

Time: 1852

State: Has readallrelay log; waiting for the slave I/O thread to updateit

Info: NULL

*************************** 3.row***************************

Id: 5

User: root

Host: localhost: 2152

db: test

Command: Query

Time: 0

State: NULL

Info: showprocesslist

3rowsinset( 0.00sec)

行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的二进制日记文件。

(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来得到一个数据快照可分为以下几步：

(1)冷拷贝(cold copy)

• 制止master，将master的文件拷贝到slave；然后重启master。缺点很显着。

制止master，将master的文件拷贝到slave；然后重启master。缺点很显着。

(2)热拷贝(warm copy)

• 假如你仅利用MyISAM表，你可以利用mysqlhotcopy拷贝，纵然服务器正在运行。

假如你仅利用MyISAM表，你可以利用mysqlhotcopy拷贝，纵然服务器正在运行。

(3)利用mysqldump

• <1>锁表：假如你还没有锁表，你应该对表加锁，防止别的毗连修改数据库，否则，你得到的数据可以是不同等的。如下：

• 利用mysqldump来得到一个数据快照可分为以下几步：

<1>锁表：假如你还没有锁表，你应该对表加锁，防止别的毗连修改数据库，否则，你得到的数据可以是不同等的。如下：

利用mysqldump来得到一个数据快照可分为以下几步：

• <2>在另一个毗连用mysqldump创建一个你想举行复制的数据库的转储：

<2>在另一个毗连用mysqldump创建一个你想举行复制的数据库的转储：

• <3>对表开释锁。

<3>对表开释锁。

深入相识复制

已经讨论了关于复制的一些根本东西，下面深入讨论一下复制。

基于语句的复制(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> INSERTINTOsummary_table(col1, col2, sum_col3)

-> SELECTcol1, col2, sum(col3)

-> FROMenormous_table

-> GROUPBYcol1, col2;

假设，只有三种唯一的col1和col2的组合，但是，该查询会扫描原表的很多行，却仅返回三条记载。此时，基于记载的复制服从更高。

另一方面，下面的语句，基于语句的复制更有用：

mysql> UPDATEenormous_table SETcol1 = 0;

此时利用基于记载的复制代价会非常高。由于两种方式不能对全部环境都能很好的处置惩罚，以是，MySQL 5.1支持在基于语句的复制和基于记载的复制之前动态互换。你可以通过设置session变量binlog_format来举行控制。

复制相干的文件

除了二进制日记和中继日记文件外，另有别的一些与复制相干的文件。如下：

• (1)mysql-bin.index

(1)mysql-bin.index

服务器一旦开启二进制日记，会产生一个与二日记文件同名，但是以.index末端的文件。它用于跟踪磁盘上存在哪些二进制日记文件。MySQL用它来定位二进制日记文件。它的内容如下(我的呆板上)：

• (2)mysql-relay-bin.index

(2)mysql-relay-bin.index

该文件的功能与mysql-bin.index雷同，但是它是针对中继日记，而不是二进制日记。内容如下：

.mysql-02-relay-bin.000017

.mysql-02-relay-bin.000018

• (3)master.info

(3)master.info

生存master的相干信息。不要删除它，否则，slave重启后不能毗连master。内容如下(我的呆板上)：

I/O线程更新master.info文件，内容如下(我的呆板上)：

.mysql-02-relay-bin.000019

254

mysql-01-bin.000010

286

0

52813

• (4)relay-log.info

(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的更新。

(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，用于劫难规复；

(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> UPDATEtbl SETcol= col+ 1;

#在第二个服务器上实行：

mysql> UPDATEtbl SETcol= 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> stopslave;

ERROR 1192 (HY000): Can't executethe given command because you have active lockedtablesoran active transaction

错误三： 在没有制止slave历程的环境下change master

mysql> changemastertomaster_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 forreplication to work (or the --replicate-same-server-id option must be used on

slave but this does not always make sense; please check the manual before using it).

#检察server-id

mysql> show variables like 'server_id';

#手动修改server-id

mysql> setglobal 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状态:

1、在从库查抄slave状态:

• 2、在主库查抄mysql-bin.001574的偏移量位置

2、在主库查抄mysql-bin.001574的偏移量位置

tail -10 ./mysql-bin.001574.bak

• 3、重新设置salve

3、重新设置salve

mysql> changemastertomaster_log_file= 'mysql-bin.001574',master_log_pos= 4059237;

mysql> startslave;

错误8： 数据同步非常环境

• 第一种：在master上删除一条记载，而slave上找不到。

第一种：在master上删除一条记载，而slave上找不到。

办理方法：由于master要删除一条记载，而slave上找不到故报错，这种环境主上都将其删除了，那么从机可以直接跳过。可用下令：

stop slave;

setglobal sql_slave_skip_counter=1;

start slave;

• 第二种：主键重复。在slave已经有该记载，又在master上插入了同一条记载。

第二种：主键重复。在slave已经有该记载，又在master上插入了同一条记载。

Duplicate entry '2' for key 'PRIMARY',

Error_code: 1062;

handlererrorHA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924

办理方法：在slave删除重复的主键.

• 第三种：在master上更新一条记载，而slave上找不到，丢失了数据。

第三种：在master上更新一条记载，而slave上找不到，丢失了数据。

Can't find record in 't1',

Error_code: 1032;

handlererrorHA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263

办理方法：把丢失的数据在slave上弥补，然后跳过报错即可。

insertintot1 values( 2, 'BTV');

stopslave; setglobalsql_slave_skip_counter= 1; startslave;

END返回搜狐，检察更多

责任编辑：