MySQL 复制介绍：
MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。
MySQL主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
在当前的生产工作中，大多数应用的 MySQL 主从同步都是异步的复制方式，即不是严格实时的数据同步。
如果你想要设置链式复制服务器，从服务器本身也可以充当主服务器。
需要注意的是，当你在进行复制时，所有对复制中的表的更新必须在主服务器上进行，这样做的目的是为了避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间产生冲突。
MySQL复制架构介绍
MySQL的复制架构除了上面说的主从复制（同步）之外，还有主主复制（同步）以及多主环状复制（同步）。
假设，我们使用了环状或者链式级联复制，那么我们的从（Slave）服务器本身除了充当从服务器之外，还需要同时充当其下面从服务器的主服务器。
相关主从复制架构，主主复制架构以及环状、链式级联复制架构图，我们可以看下面的图例：
1、单向主从同步逻辑架构图
2、双向主主同步逻辑架构图
3、线性级联单向双主同步逻辑架构图
4、环状级联单向多主同步逻辑架构图
5、环状级联单向多主多从同步逻辑架构图
MySQL 复制的优势：
这里主要以 主从复制 的为例：
MySQL 主从复制有利于增加整个数据库的健壮性、提升访问速度，并且易于维护管理。
1、增加健壮性
主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。
2、提升访问速度
通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。SELECT 查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改数据的语句仍然应发送到主服务器，以便主服务器和从服务器保持同步。如果非更新查询为主，该负载均衡策略很有效，但一般是更新查询。这也正是我们生产常用的读写分离。
3、易于维护管理
公司内部开发和维护人员，可以在一台从服务器上做后台访问、数据分析和脚本操作，特别是使用一个从服务器执行备份，这样就不会干扰主服务器的运行性能。在备份过程中，主服务器可以继续处理更新操作。
MySQL 复制的应用场景：
这里还是主要以 主从复制 的生产应用场景为例：
1）主从服务器互为备份
主从服务器架构的设置，可以大大的加强数据库架构的健壮性。例如：当主服务器出现问题时，我们可以人工或自动切换到从服务器继续提供服务。
2）主从服务器读写分离，分担网站压力
主从服务器架构可通过程序或代理软件对用户（客户端）的请求实现读写分离，即通过在从服务器上仅仅处理用户的select查询请求，降低用户查询响应时间及读写同时在主服务器带来的压力。对于更新的数据（update，insert，delete）仍然交给主服务器处理，确保主服务器和从服务器保持实时同步。
如果网站是以非更新（以浏览为主）为主的业务，如博客或者首页展示等业务，查询请求比较多，此时从服务器的读写分离、负载均衡策略就会非常有效，这就是读写分离数据库结构了。
3）根据服务器拆分业务独立并分担压力
生产中可以把几个不同的从服务器，根据公司的业务进行拆分。例如：有为外部用户提供查询服务的从服务器，有DBA用来备份的从服务器，还有提供公司内部人员访问的后台、脚本，日志分析及开发人员服务的从服务器。这样的拆分不仅会减轻主服务器的压力，而且使对外用户浏览、对内处理公司内部用户业务以及 DBA 备份业务互不影响。
请看如下主从架构生产环境从服务器分业务拆分使用案例：
master ┌ --> Slave1 --> 对外部用户提供服务（浏览帖子、游览博客、浏览文章） ├ --> Slave2 --> 对外部用户提供服务（浏览帖子、游览博客、浏览文章） ├ --> Slave3 --> 对外部用户提供服务（浏览帖子、游览博客、浏览文章） ├ --> Slave4 --> 对内部管理人员提供服务（后台访问、脚本任务、数据分析、开发人员浏览） └ --> Slave5 --> 开启从服务器 binlog 功能，可实现增量备份及恢复
MySQL 数据复制的原理
MySQL 复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，必须在主服务器上启用二进制日志。
每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新，以便从服务器可以对其数据拷贝执行相同的更新。
认识到二进制日志只是一个从启用二进制日志的固定时间点开始的记录非常重要。任何设置的从服务器需要主服务器上的（在主服务器上启用二进制日志时的）数据库拷贝。如果启动从服务器时，其数据库与主服务器上的启动二进制日志时的状态不相同，从服务器很可能失败。
将主服务器的数据拷贝到从服务器的常用途径是，使用mysqldump对主服务器上的SQL进行转储，然后在从服务器上进行恢复。需要注意的是，在主服务器使用mysqldump进行SQL转储之前，需要进行锁表操作，并记录当时的binlog日志及位置点！
MySQL数据复制的原理图大致如下：(此图来自于高性能MySQL这本书)
从上图，我们可以看出 MySQL 数据库的复制需要启动三个线程来实现：
其中一个在主服务器上，另两个在从服务器上。
1、当从服务器执行 START SLAVE 时，就表示开启主从复制开关
2、此时，从服务器本身会创建一个 I/O 线程，通过主服务器上授权的复制用户权限请求连接主服务器，并请求从指定 Binlog 日志文件的指定位置点（日志文件名和位置点信息就是在配置主从复制服务时，执行change master命令时给定的）之后发送 binlog 日志（即SQL语句）；
3、主服务器接收到来自从服务器的I/O线程请求之后，主服务器会创建一个 Binlog dump 线程，该线程会根据从服务器I/O线程请求的信息去读取指定Binlog 日志文件中指定位置点之后的 Binlog 日志信息，然后返回给从服务器的 I/O 线程。返回的信息中，除了 Binlog 日志内容之外，还有包括主服务器上最新的 Binlog 文件名以及在该 Binlog 中的最新的指定更新位置点（即下一次从服务器请求的Binlog文件名和位置点信息）。
4、当从服务器的 I/O 线程获取到主服务器上 Binlog dump 线程发送过来的日志内容及最新的日志文件名及位置点之后，它会将 Binlog 日志内容依次写入到从服务器本身的Relay Log（即中继日志）文件（Mysql-relay-bin.xxxx）的最末端，并将新的 Binlog 文件名和位置点信息记录到 master-info 文件中，以便下一次读取主服务器的最新 Binlog 日志时，能够告诉主服务器需要从最新 Binlog 日志的哪个文件的哪个位置点开始请求新的 Binlog 日志内容。
5、从服务器的 SQL 线程会实时的检测本地 Relay Log 中是否有新增加的日志内容，如果有它会就及时的把 Relay Log 文件中的内容解析成在主服务器曾经执行过的 SQL 语句内容，并在从服务器自身按语句的顺序执行对应的这些 SQL 语句，应用完毕后会自动清理应用过的日志。
这样一来，在从服务器上读取和执行语句被分成两个独立的任务。如果语句执行较慢则语句读取任务没有慢下来。例如，如果从服务器有一段时间没有运行了，当从服务器启动时，其I/O线程可以很快地从主服务器索取所有二进制日志内容，即使 SQL 线程远远滞后。如果从服务器在 SQL 线程执行完所有索取的语句前停止，I/O 线程至少已经索取了所有内容，以便语句的安全拷贝保存到本地从服务器的中继日志中，供从服务器下次启动时执行。这样就允许清空主服务器上的二进制日志，因为不再需要等候从服务器来索取其内容。
6、经过了上面的一系列过程，Mysql就能够确保在主服务器和从服务器上都执行了同样的 SQL 语句。在复制状态正常的情况下，主服务器和从服务器的数据是完全一样的。虽然 Mysql 的同步机制会有一些特殊的情况，但大多数情况都有解决方案，因此无须担心。至于更多的详细信息和更权威的信息，请参考官方手册的说明。
本文出自 “Not Only Linux” 博客，请务必保留此出处http://nolinux.blog.51cto.com/4824967/1528519
原文地址：http://nolinux.blog.51cto.com/4824967/1528519
