复制解决的问题：
备份：从库的数据是完全来自主库的，是主库的副本。
负载均衡：主库用来写数据，从库用来读数据，这种架构在一定程度上可以减轻主库的压力
高可用性和故障切换：当主库挂掉之后,程序只需要改变下DB服务器的链接Ip ，系统又可对外提供服务，
MySQL升级测试：mysql版本是向后兼容的,从库的版本只能和主库一样或是高于主库，当我们需要对服务器升级时 ，
搭建主从对MySQL高版本进行测试，是一个很不错的选择
2.复制的原理
(1)主库将数据更改操作记录到二进制日志中(根据事务的提交顺序来记录数据更改操作)
(2)备库将二进制日志复制到自己的中继日志中，这个由从库上的Io线程完成
(3)备库读取中继日志中德事件,将其重放到备库的数据上，这个由从库的sql线程完成
3.复制架构。
主从复制：所谓主从复制就是一台机器作为主服务器，
另外一台或是多台作为从库。从库可以作为主库的一个备份，当主库发生故障时立刻
使用从库替代主库对外提供读写服务。这种架构保证了DB的高可用性。
主从复制也可以实现负载均衡,主库对外提供写服务 ,从库提供读服务。
这种架构有效的减少了主库的压力。
主主复制：所谓主主复制就是两台机器彼此扮演着从库角色。两胎机器同时对外提供服务。
这种复制架构虽然在一定程度上扩展了MySQL的读写能力，但是这种架构的容易导致数据的不完整。
例如。当复制断开或是延时过大时就会造成整个数据的不完整。所以个人建议不要要在生产环境中
使用此种架构。
值得注意的是MySQL只支持一主多从，不支持一从多主的。
4.复制配置：
(1)主库需要在my.cnf 文件配置一下参数
log_bin = binlog ：主库一定要开启二进制日志
server_id = 1 ： 在一个完整的复制架构中实例Id不能一样,实例Id会记录在二进制日志中。
创建一个复制账号，该账号用户从库链接到主库读取二进制日志时使用的,
Grant replication slave ,replication client on *.* to repl@‘192.168.1.%‘ identified by ‘12344‘
(2)从库上的my.cnf需要配置的参数：
server_id = 2 ：在一个完整的复制架构中实例Id不能一样,实例Id会记录在二进制日志中。
(3)指定复制的位置
change master to
master_host=‘serveName‘
,master_user=‘repl‘
,master_password=‘12344‘
,master_port=3306
,master_log_file=‘binlogfileName‘
master_log_Pos=4
参数解释：
master_host：主库的服务器Ip
master_user:从库连接到主库的用户名,
master_password:从库连接到主库的密码
master_port:主库的访问端口
master_log_file：复制的二进制文件名 ,
master_log_Pos：开始复制的位置
master_log_file ,master_log_Pos
这两个参数的值根据复制的具体的情况可以使用不同的方式得到。
例如：搭建复制环境中主库停止了对外服务，那么可以直接在主库上
mysql> show master status ;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000025 | 106 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
如果在搭建复制的过程中主库在不停的对外提供服务，可以通过两种方式
获取master_log_file ,master_log_Pos 的值
mysqldump:使用该备份命令时一定要记得添加--master-data 参数 ，
master_log_file ,master_log_Pos的值会记录在备份文件的文件头部
Xtrabackup ：这是一个第三方的备份工具，二进制文件名和位置信息被保存在一个文件中。
(4)开启复制
start slave ;
按照以上的步骤可以搭建一个简单的复制,但是在实际的生产环境中
要比以上配置要复杂很多。
例如在生产环境中要考虑到数据的安全性(数据的安全性在生产环境中是非常中重要的)。
复制指定的库,在读写的分离的架构中，从库的用户权限和主库中的用户权限可能不需要一样,
这时就可以过滤掉指定库(或者复制指定库) 。
5.以下参数是配置复制可能需要用到的变量
log_bin = binlog : 该参数可以在备库中开启也可以不开启，不过在主主复制架构中，一定要开启该参数。
relay_log=relaylog ：中继日志的文件名
log_slave_updates = 1 ：重放中继日志时是否将重放类容写入到本地(从库)的二进制日志中,在主主复制架构中一定要开启开启这个参数。
read_only = 1 ：这个参数防止没有特权权限的用户修改从库数据,导致主从数据不一致。
replicate_ignore_db = DBname ：指定不需要复制的数据库 。
replicate_do_db = DBname ：明确指定需要复制的数据库 ，其他数据库不复制
replicate_wild_do_table = DBname.% :复制指定的表
sync_binlog = 1 ：这个参数可以保证数据的安全性,在事务提交前保证二进制日志已经写入磁盘
innodb_flush_log_at_trx_commit = 1：这个参数保证事务的安全性,默认值为1
sync_master_info = 1: 保证文件master.info的安全性
sync_relay_log = 1: 保证relay_log.info的安全性
sync_relay_log_info = 1:保证relay_log.info的安全性
6.复制的控制。
start slave :开启复制
stop slave :关闭复制
stop slave IO_thread :关闭Io线程
stop slave sql_thread:关闭sql线程
start slave IO_thread:开启Io线程
start slave sql_thread : 开启sql线程
show slave status \G;查看复制的得状态，
一般情况下如果从库和主库没有延时,Seconds_behind_master的就为0
该命令的更多参数以后会慢慢讲解到。
搭建复制的三种情况，如何保证主从数据完全一致？
(1).主库还未对外提供服务
(2).主库正在运行中
(3).向已有的复制架构中添加新的复制库
问题1.如何监控主从是否一致。 Percona Toolkit(pt-table-checksum)
问题2.如何快速恢复主从同步。Percona Toolkit(pt-table-sync)
问题3.半同步复制
本文出自 “SQLServer MySQL” 博客，请务必保留此出处http://dwchaoyue.blog.51cto.com/2826417/1545404