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/