1.	复制概述
1.1 mysql支持的复制类型
1.2 复制解决的问题
1.3 复制如何工作
2. 2 复制配置
2.1创建复制帐号
2.2拷贝数据
2.3配置master
2.4配置slave
2.5启动slave
2.6添加新slave服务器
3. 深入了解复制
3.1基于语句的复制Statement-Based Replication
3.2基于记录的复制Row-Based Replication
3.3复制相关的文件
3.3.11mysql-binindex
3.3.2mysql-relay-binindex
3.3.3masterinfo
3.3.4relay-loginfo
3.3.4发送复制事件到其它slave
3.3.5复制过滤Replication Filters
4. 复制的常用拓扑结构
4.1单一master和多slave
4.2主动模式的Master-MasterMaster-Master in Active-Active Mode
4.3主动-被动模式的Master-MasterMaster-Master in Active-Passive Mode
4.4 级联复制架构 Master Slaves - Slaves
4.5带从服务器的Master-Master结构Master-Master with Slaves

目录

1 复制概述

  Mysql内建的复制功能是构建大型,高性能应用程序的基础。将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。

  请注意当你进行复制时,所有对复制中的表的更新必须在主服务器上进行。否则,你必须要小心,以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。

1.1 mysql支持的复制类型:

  (1):基于语句的复制:  在主服务器上执行的SQL语句,在从服务器上执行同样的语句。MySQL默认采用基于语句的复制,效率比较高。  
            一旦发现没法精确复制时,   会自动选着基于行的复制。    
  (2):基于行的复制:把改变的内容复制过去,而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持
  (3):混合类型的复制: 默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。

1.2 . 复制解决的问题

MySQL复制技术有以下一些特点:
         (1)    数据分布 (Data distribution )
         (2)    负载平衡(load balancing)
         (3)    备份(Backups) 
         (4)    高可用性和容错行 High availability and failover

1.3 复制如何工作

  整体上来说,复制有3个步骤:

   (1)    master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events);
     (2)    slave将master的binary log events拷贝到它的中继日志(relay log);
     (3)    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上并行操作。

2 .复制配置

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

要点:
负责在主、从服务器传输各种修改动作的媒介是主服务器的二进制变更日志,这个日志记载着需要传输给从服务器的各种修改动作。因此,主服务器必须激活二进制日志功能。从服务器必须具备足以让它连接主服务器并请求主服务器把二进制变更日志传输给它的权限。
        
环境:
Master和slave的MySQL数据库版本同为5.0.18
操作系统:unbuntu 11.10
IP地址:10.100.0.100

2.1、创建复制帐号

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'))

2.2、拷贝数据

(假如是你完全新安装mysql主从服务器,这个一步就不需要。因为新安装的master和slave有相同的数据)

关停Master服务器,将Master中的数据拷贝到B服务器中,使得Master和slave中的数据同步,并且确保在全部设置操作结束前,禁止在Masterslave服务器中进行写操作,使得两数据库中的数据一定要相同!

2.3、配置master

接下来对master进行配置,包括打开二进制日志,指定唯一的servr ID。例如,在配置文件加入如下值:

server-id=1
log-bin=mysql-bin

server-id:为主服务器A的ID值
log-bin:二进制变更日值

重启master,运行SHOW MASTER STATUS,输出如下:

2.4、配置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是必须的,而且唯一。slave没有必要开启二进制日志,但是在一些情况下,必须设置,例如,如果slave为其它slave的master,必须设置bin_log。在这里,我们开启了二进制日志,而且显示的命名(默认名称为hostname,但是,如果hostname改变则会出现问题)。
relay_log配置中继日志,log_slave_updates表示slave将复制事件写进自己的二进制日志(后面会看到它的用处)。
有些人开启了slave的二进制日志,却没有设置log_slave_updates,然后查看slave的数据是否改变,这是一种错误的配置。所以,尽量使用read_only,它防止改变数据(除了特殊的线程)。但是,read_only并是很实用,特别是那些需要在slave上创建表的应用。

2.5、启动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 STATUS\G

*************************** 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> START SLAVE;

运行SHOW SLAVE STATUS查看输出结果:

  mysql> SHOW SLAVE STATUS\G

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

Slave_IO_State: Waiting for master to send 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的I/O和SQL线程都已经开始运行,而且Seconds_Behind_Master不再是NULL。日志的位置增加了,意味着一些事件被获取并执行了。如果你在master上进行修改,你可以在slave上看到各种日志文件的位置的变化,同样,你也可以看到数据库中数据的变化。

  你可查看master和slave上线程的状态。在master上,你可以看到slave的I/O线程创建的连接:

在master上输入show processlist\G;

mysql> show processlist \G

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

Id: 1

User: root

Host: localhost:2096

db: test

Command: Query

Time: 0

State: NULL

Info: show processlist

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

Id: 2

User: repl

Host: localhost:2144

db: NULL

Command: Binlog Dump

Time: 1838

State: Has sent all binlog to slave; waiting for binlog to be updated

Info: NULL

2 rows in set (0.00 sec)

2为处理slaveI/O线程的连接。

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

mysql> show processlist \G

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

Id: 1

User: system user

Host:

db: NULL

Command: Connect

Time: 2291

State: Waiting for master to send event

Info: NULL

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

Id: 2

User: system user

Host:

db: NULL

Command: Connect

Time: 1852

State: Has read all relay log; waiting for the slave I/O thread to update it

Info: NULL

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

Id: 5

User: root

Host: localhost:2152

db: test

Command: Query

Time: 0

State: NULL

Info: show processlist

3 rows in set (0.00 sec)

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

2.5、添加新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
  使用mysqldump来得到一个数据快照可分为以下几步:
<1>锁表:如果你还没有锁表,你应该对表加锁,防止其它连接修改数据库,否则,你得到的数据可以是不一致的。如下:
  mysql> FLUSH TABLES WITH READ LOCK;
<2>在另一个连接用mysqldump创建一个你想进行复制的数据库的转储:
  shell> mysqldump --all-databases --lock-all-tables >dbdump.db
<3>对表释放锁。
  mysql> UNLOCK TABLES;

3、深入了解复制

 

 这种方式的优点就是实现简单。此外,基于语句的复制的二进制日志可以很好的进行压缩,而且日志的数据量也较小,占用带宽少——例如,一个更新GB的数据的查询仅需要几十个字节的二进制日志。而mysqlbinlog对于基于语句的日志处理十分方便。       但是,基于语句的复制并不是像它看起来那么简单,因为一些查询语句依赖于master的特定条件,例如,master与slave可能有不同的时间。所以,MySQL的二进制日志的格式不仅仅是查询语句,还包括一些元数据信息,例如,当前的时间戳。即使如此,还是有一些语句,比如,CURRENT USER函数,不能正确的进行复制。此外,存储过程和触发器也是一个问题。     另外一个问题就是基于语句的复制必须是串行化的。这要求大量特殊的代码,配置,例如InnoDB的next-key锁等。并不是所有的存储引擎都支持基于语句的复制。

 

对于一些语句,基于记录的复制能够更有效的工作,如:
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来进行控制。

 
 

我的机器上):

 

(2)mysql-relay-bin.index

.\mysql-02-relay-bin.000017
.\mysql-02-relay-bin.000018

 

I/O线程更新master.info文件,内容如下(我的机器上):

(4)relay-log.info

 

4、复制的常用拓扑结构

(1)    每个slave只能有一个master;
(2)    每个slave只能有一个唯一的服务器ID;
(3)    每个master可以有很多slave;
(4)    如果你设置log_slave_updates,slave可以是其它slave的master,从而扩散master的更新。


  如果写操作较少,而读操作很时,可以采取这种结构。你可以将读操作分布到其它的slave,从而减小master的压力。但是,这种结构虽然简单,但是,它却非常灵活,足够满足大多数应用需求。一些建议:

(1)    不同的slave扮演不同的作用(例如使用不同的索引,或者不同的存储引擎);

(2)    用一个slave作为备用master,只进行复制;

(3)    用一个远程的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中,就更不用担心可能会出现循环复制的情形了。

 

在第一个服务器上执行:
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结合起来,可以建立强大的高性能的数据库平台。但是,可以通过其它一些方式来模拟这种多主服务器的复制。

 
 
 
 

4.5、带从服务器的Master-Master结构(Master-Master with Slaves)

级联复制在一定程度上面确实解决了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集群可能出现的数据延时也会更为明显,所以考虑使用多层级联复制之前,也需要评估数据延时对应用系统的影响。

 

高性能Mysql主从架构的复制原理及配置的更多相关文章

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

    温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台 ...

  2. 转:高性能Mysql主从架构的复制原理及配置详解

    温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台 ...

  3. 高性能Mysql主从架构的复制原理及配置详解(转)

    温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台 ...

  4. Mysql学习总结(18)——Mysql主从架构的复制原理及配置详解

    一.复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重 ...

  5. Mysql主从架构的复制原理及配置详解

    一.简述Mysql复制 Mysql复制是通过将mysql的某一台主机的数据复制到其他主机(slaves)上,并且在slaves上重新执行一遍来实现.主服务器每次数据操作都会将更新记录到二进制日志文件, ...

  6. Mysql主从数据库架构的复制原理及配置详解

    1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重 ...

  7. Mysql主从同步的实现原理与配置实战

    1.什么是mysql主从同步? 当master(主)库的数据发生变化的时候,变化会实时的同步到slave(从)库. 2.主从同步有什么好处? 水平扩展数据库的负载能力. 容错,高可用.Failover ...

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

    一. 什么是GTID ( Global transaction identifiers ):MySQL-5.6.2开始支持,MySQL-5.6.10后完善,GTID 分成两部分,一部分是服务的UUid ...

  9. Mysql主从架构的复制

    复制类型 (1)基于语句的复制:  在主服务器上执行的SQL语句,在从服务器上执行同样的语句.MySQL默认采用基于语句的复制,效率比较高.  一旦发现没法精确复制时,会自动选着基于行的复制. (2) ...

随机推荐

  1. Good Bye 2015 F - New Year and Cleaning

    F - New Year and Cleaning 这题简直是丧心病狂折磨王.. 思路:容易想到这样一个转换,把整个矩形一起移动,矩形移出去的时候相当于一行或者一列. 为了优化找到下一个消去的点,我先 ...

  2. 超简教程:Xgboost在Window上的安装(免编译)

    Xboost在windows安装需要自己编译,编译的过程比较麻烦,而且需要复杂的软件环境.为了免去编译,我这里把编译好的文件上传到网盘供大家下载安装.有了编译好的文件,xgboost的安装变得超级简单 ...

  3. Windows 如何远程登陆 Server 的 jupyter

    jupyter 安装就不用赘述了,本示例以 Putty 为例,展示如何从本地 windows 系统调用远程的 jupyter notebook 并且在本地 Chrome 中打开的方法 1. 首先,ss ...

  4. Wannafly挑战赛7 B - codeJan与旅行

    题目描述 codeJan 非常喜欢旅行.现在有 n 个城市排在一条线上,并且 codeJan 的位置不和任何一个城市的位置重叠.codeJan 想要游览 m 个城市,同时因为时间是不断变化的,游览一个 ...

  5. zookpeer应用和zkclient实践

    分布式 zkclient 排它锁 在需要获取排它锁时,通过调用create()接口,创建临时子节点.zk会保证在所有客户端中,只有一个会创建成功,从而获取锁. 其他客户端注册该节点的变更watch监听 ...

  6. Scrapy实战篇(八)之简书用户信息全站抓取

    相对于知乎而言,简书的用户信息并没有那么详细,知乎提供了包括学习,工作等在内的一系列用户信息接口,但是简书就没有那么慷慨了.但是即便如此,我们也试图抓取一些基本信息,进行简单地细分析,至少可以看一下, ...

  7. JMS 基本可靠性机制 和 事务机制

    4.3.1 基本可靠性机制4.3.1.1 控制消息的签收(Acknowledgment) 客户端成功接收一条消息的标志是这条消息被签收.成功接收一条消息一般包括如 下三个阶段:1.客户端接收消息:2. ...

  8. Dalvik 虚拟机 jvm 区别

    韩梦飞沙  韩亚飞  313134555@qq.com  yue31313  han_meng_fei_sha dalvik 基于 寄存器, jvm基于 栈. 寄存器,编译时间会更短. dalvik ...

  9. Mac 配置几个环境变量

    终端    open -t ~/.bash_profile  打开.bash_profile export PATH=${PATH}:/Users/maxinliang/Android/sdk/pla ...

  10. poj 1733 并查集+hashmap

    题意:题目:有一个长度 已知的01串,给出多个条件,[l,r]这个区间中1的个数是奇数还是偶数,问前几个是正确的,没有矛盾 链接:点我 解题思路:hash离散化+并查集 首先我们不考虑离散化:s[x] ...