mysql主从复制，旧

旧

mysql支持两种复制方式：
　　基于行的复制和基于语句的复制（也称为逻辑复制），这两种方式都是通过在主库上记录二进制日志，在备库重放日志的方式来实现异步的数据复制。这意味着，在同一时间点备库上的数据可能和主库存在不一致，并且无法保证主备之间的延迟。一些大的语句可能导致备库产生几秒，几分钟甚至几个小时的延迟。

Mysql复制大部分是向后兼容的，新版本的服务器可以作为老版本服务器的备库，但是反过来，将老版本作为新版本服务器的备库通常是不可行的，因为它可能无法解析新版本所采用的新的特性或语法，另外所使用的二进制文件的格式也可能不相同。

 

在一主库多备库的架构中，写操作会被执行多次，这时候整个系统的性能取决于写入最慢的那部分

复制的工作原理

 

　　1.在主库上把数据更改记录到二进制日志（Binary Log）中（这些记录被称为二进制日志事件）。在每次准备提交事务完成数据更新前，主库将数据跟新的事件记录到二进制日志中。Mysql会安事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库告诉储存引擎可以提交事务了。

 　2.备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储（binlog dump）线程（该线程没有对应的sql命令），这个二进制转储线程会读取主库上二进制日志中的事件。它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眠状态，直到主库发信号通知其有新的事件产生时才会被唤醒，备库I/O线程会将接收到的事件记录到中继日志中

3.备库的sql线程读取中继日志中的事件，并在被库上执行，从而实现备库数据的更新。当Sql线程追赶上I/O线程时，中继日志通常已经在 系统缓存中，所以中继日志的开销很低，SQL线程执行的事件也可以通过配置选项来决定是否写入其自己的二进制日志中

 

配置
　　在备库运行的I/O线程会建立一个到主库的TCP/IP连接，这意味着必须在主库创建一个用户，并赋予其合适的权限。备考I/O线程以该用户名连接到主库并读取其二进制日志。通过如下语句创建用户账号：
　　Mysql> grant replication slave,replication client on *.* to  username@'host' identified by 'password' ；

　复制账号事实上只需要有主库上的replication slave权限，而用来监控和管理复制的账号都需要replication client权限，

 

在主库上开启一些设置

log_bin = mysql-bin  # 打开二进制日志，默认情况下他是根据机器名来命名的，但是如果机器名变化了可能会导致问题
server_id = 10    # 指定一个独一无二的服务器ID
重启mysql，为了确认二进制日志文件是否已经在主库上创建，使用show master status 命令检查

备库的配置
log_bin = mysql-bin #可选 ，默认情况下他是根据机器名来命名的，但是如果机器名变化了可能会导致问题
server_id = 2
relay_log = /var/lib/mysql/mysql-relay-bin   #指定中继日志的位置和命名
log_slave_updates=1      #允许备库将其重放的事件也记录到自身的二进制日志中

read_only = 1  #该选择会阻止任何没有特权权限的线程修改数据（所以最好不要给予用户超出所需的权限）
重启MySQL

有时候只开启了二进制日志，但却没有开启log_slave_updates,可能会碰到一些奇怪的现象，例如，当配置错误时可能会导致备库数据被修改，如果可能的话，最好使用read_only配置选项，该选择会阻止任何没有特权权限的线程修改数据（所以最好不要给予用户超出所需的权限）。但read_only选择常常不是很实用，特别是对于那些需要在备库创表的应用

 

 

主库上

sync_binlog = 1   #mysql每次提交事务前会将二进制日志同步到磁盘上，保证在服务器奔溃时不会丢失事件，
如果使用Innodb，强烈推荐如下选择
　　innodb_flush_logs_at_trx_commit
　　innodb_support_xa=1
　　innodb_safe_binlog

在备库上，推荐开启如下配置选项，为中继日志指定绝对路径：
　　relay_log=/path/to/logs/relay-bin
　　skip_slave_start  #选项能够阻止备库在崩溃时自启动复制，这可以给你一些机会来修复可能发生的问题
　　read_only        #阻止大部分用户更改非临时表，除了复制sql线程和其他拥有超级权限的用户之外，这也是要尽量避免给正常账号赋予超级权限的原因之一。

 

基于语句的复制
　　基于语句的复制(也称逻辑复制)，基于语句的复制模式下，主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时 ，实际上只是把主库执行过的SQL在执行一遍
　　　　

　　基于行的复制
　　　　基于行的复制，这种方式会将实际数据记录在二进制日志中，最大的好处是可以正确地复制每一行。一些语句可以被更加有效地复制
　　　　　　基于行的复制没有向后兼容性，和myql5.1一起发布的mysqlbinlog 工具可以读取基于行的复制的事件格式（它对人不是可读的，但mysql可以理解），但是早期的版本的mysqlbinlog无法识别这类事件，在遇到错误时会退出。

 

 由于没有那种模式对所有情况都是完美的;myql能够在这两种复制模式间动态切换。默认情况下使用的是基于语句的复制方式，但如果发现语句无法被正确地复制，就切换到基于行的复制模式。还可以根据需要来设置会话级别的变量binlog_format,控制二进制日志格式