Mysql replication report1 基本用途2 基本原理3 搭建过程4 导致 master 和 slave 不同步的原因5 Mysql replication 的历程6 数据库不同步的一些解决方案

Replication的用途：1 数据分发 ,scale out，sacle up ，垂直划分，水平划分2 负载均衡 load balance

3 备份，一般不会用作备份，一旦执行 delete 操作，replication 也不会保留4 高可用

5 可以在不同的主从库上使用不同的存储引擎6 测试 mysql 的升级常见 replication 的架构

常见的负载均衡架构

当使用的 slavae 过多时，减轻 master 压力的级联架构，master2 打开 log-slave-

updates 配置

一台 masterdown 时候的，冗余架构

Replication 不同的库到不同的主机

原理

1 三个进程：

Mysql 的复制（replication）是一个异步的复制，从一个 Master 复制到另一

个 Slave。实现整个复制操作主要由三个进程完成的，其中两个进程在

Slave（Sql 进程和 IO 进程），另外一个进程在 Master（IO 进程）上，可以

分别在 master 如果 replication 在进行的话可以通过运行 show processlist

查看，slave 上可以直线 show slave status 进行查看，里面的

Slave_IO_Running: No Slave_SQL_Running: No，是两个进程的状态是否

在运行。Mysql4.0 是两个进程，后有 yahoo 的一位工程师提出的 3 个进程，

博客为:http://jeremy.zawodny.com/mysql/

2 三个 log文件和两个 info文件：

复制进行时，在 master 上执行的语句会记录到 bin.log 里面，日志的位置和

数字，当有变化 放生时，slave 会通过一个 io 进程读取 master 的二进制

log，发现有变化时候，会把新的变化副知道他的 relay.log,会记录行的位置和

数字到一个新的文件叫 master.info，继续检查 master 的二进制 log，当

slave 的 sql 进程发现在 relay.log 里有变化时候会执行，同时 slave 也会通过

sql 进程去对比 master 和 slave 的变化，如果对比发现不一致，复制进程会

停止并把错误信息计入 slave 的 error.log,如果结果能对的上，一个新的日子

的位置和数字会记录到 relay-log.info slave 会等另外一个变化到 relay log

文件。

3 复制的基本过程如下：

简单的讲就是 master 记录其变化到 binlog，slave 接收到变化后会记录到他

的 Relay log，slave 通过重放 relay log，然后就写进自己的 log

1)、Slave 上面的 IO 进程连接上 Master，并请求从指定日志文件的指定位置

（或者从最开始的日志）之后的日志内容；

2)、Master 接收到来自 Slave 的 IO 进程的请求后，通过负责复制的 IO 进程根

据请求信息读取制定日志指定位置之后的日志信息，返回给 Slave 的 IO 进程。

返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到

Master 端的 bin-log 文件的名称以及 bin-log 的位置；

3)、Slave 的 IO 进程接收到信息后，将接收到的日志内容依次添加到 Slave 端

的 relay-log 文件的最末端，并将读取到的 Master 端的 bin-log 的文件名和位

置记录到 master-info 文件中，以便在下一次读取的时候能够清楚的高速

Master“我需要从某个 bin-log 的哪 个位置开始往后的日志内容，请发给我”；

4)、Slave 的 Sql 进程检测到 relay-log 中新增加了内容后，会马上解析 relay-

log 的内容成为在 Master 端真实执行时候的那些可执行的内容，并在自身执行

4 Replication的两种复制级别：

Statement level 级别 mysql 3.23 后

每一条修改数据的 query 都会记录到 master 的 binary log 中，slave 复制

时候 sql 线程会解析成合原来的 master 端执行过的相同的 query.

优点是：

不需记录每条变化，减少 log，节省 io。

缺点是：必须每条语句相关信息，即上下文信息。

Row level 级别 5.1 以后：

Binary log 会记录成每一行数据被修改的形式，然后在 slave 端口对相同的数

据进行修改。锁表操作会大量减少。

优点：不需记录执行 query 语句的上下文信息，只需要记录那条被修改了，修

改成什么了。

缺点是：产生的 log 记录比较大

还有一种不常用的 mixed 级别。

搭建过程可以参考mysql官方文档:

步骤：1 Creating a User for Replication

2 Setting the Replication Master Configuration

3 Setting the Replication Slave Configuration

4 Obtaining the Master Replication Information

5 Creating a Data Snapshot Using mysqldump

6 Creating a Data Snapshot Using Raw Data Files

7 Setting Up Replication with New Master and Slaves

8 Setting Up Replication with Existing Data

9 Introducing Additional Slaves to an Existing Replication Environment

10 Setting the Master Configuration on the Slave

导致master 和 slave 不同步的原因

1 delete update 改变行的时候不用使用 limit 语句，没有 order by

2 一些函数在使用 statements based replication 时候如下：

Lode_file,User,Found_rows,UUID, UUID_SHORT,SYSDATE(),

2 使用 session 变量在 sql 语句中，他会导致写到 binlog 里，老版本会出问题

3 不用使用临时表，当 slave crash掉或者重启后，会丢失信息

4 slave down掉

5 使用 replicate-ignore-db 和 binlog-ignore-db.

6 错误的 binglog 执行 sql 导致 binlog 堵上具体可以详见：http://dev.mysql.com/doc/refman/5.0/en/replication.html

5 mysql replication的历程

mysql版本的 4.0-5．0：

Mysql 5.1

未来 6.0 和 5.4 的新功能：

不分主从库，可以循环 replication。

去掉一个 server 后

加入心跳监测 replication：

自动监测连接状态

Master空闲时，relay log 不在循环

监测 master 和 slave 的配置在 millisecons

5.1版本的 replication 的改变：

250 replication bug 关闭

重构了 slave 的 postion handle 部分

修改了一些在 statement 不安全的复制 binglog model

不安全的状态改变的语句会提示警告

自动的引擎控制日志格式

改变了一些配置

参考：http://onlamp.com/pub/a/onlamp/2005/06/16/MySQLian.html

http://mysqlha.blogspot.com/2007/11/how-to-keep-mysql-replication-in-sync.html