mysql 复制

1. 复制解决的问题：

备份：从库的数据是完全来自主库的，是主库的副本。

负载均衡：主库用来写数据，从库用来读数据，这种架构在一定程度上可以减轻主库的压力

高可用性和故障切换：当主库挂掉之后,程序只需要改变下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_do_table: 复制指定的表(安全)

replicate_ignore_table: 不复制指定的表(安全)

replicate_wild_do_table = DBname.% :复制指定的表,安全，推荐使用该参数复制指定的库，值得注意注意的是该参数支持通配符.replicate_wild_do_table = DBna%.%

replicate_Wild_ignore_table:不复制指定的库或表 (db_vip%.%)

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.半同步复制

参考链接！

http://blog.itpub.net/15688952/viewspace-700144/