主从复制
一、定义
二、作用
三、原理
四、GTID复制（基于事务ID复制）
1.GTID定义
2.工作原理
3.部署实例
五、Binlog日志主从复制
1.环境
2.准实验前备工作
3.主服务器：
4.从服务器：
5.测试

一、定义
  主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。
二、作用

1.做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。

2.架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率,提高单个机器的I/O性能。

3.读写分离，使数据库能支撑更大的并发。

  1）在从服务器可以执行查询工作，降低主服务器压力;（主库写，从库读）

  2）在从服务器进行备份，避免备份期间影响主服务器服务;（确保数据安全）

三、原理
  实现整个主从复制，需要由slave服务器上的IO进程和Sql进程共同完成。要实现主从复制，首先必须打开Master端的binary log（bin-log）功能，因为整个MySQL 复制过程实际上就是Slave从Master端获取相应的二进制日志，然后再在自己slave端完全顺序的执行日志中所记录的各种操作。

步骤一：主库db的更新事件(update、insert、delete)被写到binlog

步骤二：从库发起连接，连接到主库

步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库

步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.

步骤五：还会创建一个SQL线程，从relay log里面读取内容，将更新内容写入到slave的db.

四、GTID复制（基于事务ID复制）
1.GTID定义
  全局事务标识：global transaction identifiers，是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。
2.工作原理

1）master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

2）slave端的i/o 线程将变更的binlog，写入到本地的relay log中。

3）sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

4）如果有记录，说明该GTID的事务已经执行，slave会忽略。

5）如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

3.部署实例
1）实验环境

两台机器：

192.168.246.129  mysql-master

192.168.246.128  mysql-slave
2）实验基础

1>关闭防火墙和selinux

2>添加域名

#vim /ect/hosts			//追加

192.168.246.129  master

192.168.246.128  slave

3>安装MySQL

4>重启查看是否成功
#systemctl start mysqld
#systemctl enable mysqld
#netstat -lntp | grep 3306
tcp6  0   0 :::3306    ::: *      LISTEN     11669/mysqld

3）主机操作
[root@mysql-master ~]# vim /etc/my.cnf  	 //在[mysqld]下添加
server-id=1   								//定义server id master必写 
log-bin = mylog 							//开启binlog日志，master比写
gtid_mode = ON    							//开启gtid
enforce_gtid_consistency=1   				//强制gtid
[root@mysql-master ~]# systemctl restart mysqld
[root@mysql-master ~]# mysql -uroot -p'QFljc,521'
mysql> grant all on *.* to 'slave'@'%' identified by 'Qf@12345';		//可修改权限
mysql> flush privileges;

4）从机操作
[root@mysql-slave ~]# vim /etc/my.cnf  		//添加如下配置
server-id=2									//标识，防止复制出错
gtid_mode = ON
enforce_gtid_consistency=1
master-info-repository=TABLE				//可无，定义配置
relay-log-info-repository=TABLE				//可无，定义配置
[root@mysql-slave ~]# systemctl restart mysqld
[root@mysql-slave ~]# mysql -uroot -p'QFljc,521'
mysql> \e
change master to
master_host='master',     					 //主机地址,最好用域名
master_user='slave',     					//主服务上面创建的用户
master_password='Qf@12345', 				//用户密码
master_auto_position=1;						//启动变量布尔值
-> ;
mysql> start slave;
mysql> show slave status\G					//查看slave状态，均为yes即为成功


5）测试

主机：
mysql > insert into test.t1(1);

从机：
mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
+------+

五、Binlog日志主从复制
1.环境
两台机器

192.168.246.135    mysql-master

192.168.246.136    mysql-slave
2.准实验前备工作
1）关闭防火墙和selinux

2）安装MySQL并修改密码

3）添加域名解析

#vim /ect/hosts	   //追加

192.168.246.129  master

192.168.246.128  slave
3.主服务器：
[root@mysql-master ~]#vim /etc/my.cnf		//添加配置
[mysqld]
log-bin=/var/log/mysql/mysql-bin		//开启binlog日志，并设置存储位置
server-id=1
[root@mysql-master ~]# mkdir /var/log/mysql
[root@mysql-master ~]# chown mysql.mysql /var/log/mysql
[root@mysql-master ~]# systemctl restart mysqld
[root@mysql-master ~]# mysql -uroot -p'QFljc,521'
mysql> GRANT ALL ON *.*  TO  'repl'@'%'  identified by 'Qf@12345';
mysql> flush privileges;
mysql> show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000002
         Position: 154
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 
1 row in set (0.00 sec)

4.从服务器：
[root@mysql-slave ~]#vim /etc/my.cnf		
[mysqld]
server-id=2
[root@mysql-slave ~]# systemctl restart mysqld
[root@mysql-slave ~]# mysql -uroot -p'QFljc,521'
mysql> \e
CHANGE MASTER TO
MASTER_HOST='mysql-master',			//主服务器域名
MASTER_USER='repl',					//用户买名
MASTER_PASSWORD='Qf@12345!',		//密码
MASTER_LOG_FILE='mysql-bin.000001',	//日志文件名
MASTER_LOG_POS=849;				//日志内容位置
    -> ;
mysql> start slave;
mysql> show slave status\G

5.测试
主服务器：
mysql> create table dai.aa(id int);
mysql> insert into dai.aa values(111);
mysql> insert into dai.aa values(222);

从服务器：
mysql> select * from dai.aa;
+------+
| id   |
+------+
|  111 |
|  222 |
+------+
2 rows in set (0.01 sec)

MySQL三大日志及主从复制的原理
文章目录
MySQL三大日志及主从复制的原理
一、binlog
1.概念
2.分类
3.binlog使用场景
4.binlog刷盘时机
5.binlog日志格式
二、redo log
1.为什么需要redo log
2.redo log基本概念
3.redo log记录形式
4.redo log与binlog区别
三、undo log
四、主从复制的原理
1.什么是主从复制?
2.主从复制的作用
3.主从复制的原理
4.总结


日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。

mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。
作为开发，我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)。
一、binlog
1.概念

 binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。

2.分类


 逻辑日志：可以简单理解为记录的就是sql语句。


 物理日志：因为mysql数据最终是保存在数据页中的，物理日志记录的就是数据页变更。


binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。


3.binlog使用场景
在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。

 主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
 数据恢复：通过使用mysqlbinlog工具来恢复数据。

4.binlog刷盘时机
对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中，那么biglog是什么时候刷到磁盘中的呢？mysql通过sync_binlog参数控制biglog的刷盘时机，取值范围是0-N：

 0：不去强制要求，由系统自行判断何时写入磁盘；
 1：每次commit的时候都要将binlog写入磁盘；
 N：每N个事务，才会将binlog写入磁盘。

从上面可以看出，sync_binlog最安全的是设置是1，这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。
5.binlog日志格式
binlog日志有三种格式，分别为STATMENT、ROW和MIXED。
在 MySQL 5.7.7之前，默认的格式是STATEMENT，MySQL 5.7.7之后，默认值是ROW。日志格式通过binlog-format指定。

 STATMENT
基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 从而提高了性能；
缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp()等。
 ROW
基于行的复制(row-based replication, RBR)，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。
优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题；
缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨
 MIXED
基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog

二、redo log
1.为什么需要redo log

 我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。
 那么mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。
 但是这么做会有严重的性能问题，主要体现在两个方面：
因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！
一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！

因此mysql设计了redo log，具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
2.redo log基本概念

 redo log包括两部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。
 mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。
 在计算机操作系统中，用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的，中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)。
 因此，redo log buffer写入redo log file实际上是先写入OS Buffer，然后再通过系统调用fsync()将其刷到redo log file中，过程如下：


mysql支持三种将redo log buffer写入redo log file的时机，可以通过innodb_flush_log_at_trx_commit参数配置，各参数值含义如下：




3.redo log记录形式

 前面说过，redo log实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此redo log实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。如下图：


同时我们很容易得知，在innodb中，既有redo log需要刷盘，还有数据页也需要刷盘，redo log存在的意义主要就是降低对数据页刷盘的要求。
在上图中，write pos表示redo log当前记录的LSN(逻辑序列号)位置，check point表示数据页更改记录刷盘后对应redo log所处的LSN(逻辑序列号)位置。
write pos到check point之间的部分是redo log空着的部分，用于记录新的记录；
check point到write pos之间是redo log待落盘的数据页更改记录。
当write pos追上check point时，会先推动check point向前移动，空出位置再记录新的日志。
启动innodb的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为redo log记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如binlog)要快很多。
重启innodb时，首先会检查磁盘中数据页的LSN，如果数据页的LSN小于日志中的LSN，则会从checkpoint开始恢复。
还有一种情况，在宕机前正处于checkpoint的刷盘过程，且数据页的刷盘进度超过了日志页的刷盘进度，此时会出现数据页中记录的LSN大于日志中的LSN，这时超出日志进度的部分将不会重做，因为这本身就表示已经做过的事情，无需再重做。



4.redo log与binlog区别

 由binlog和redo log的区别可知：binlog日志只用于归档，只依靠binlog是没有crash-safe能力的。
 但只有redo log也不行，因为redo log是InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。

三、undo log
数据库事务四大特性中有一个是原子性，具体来说就是 原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。
实际上，原子性底层就是通过undo log实现的。

 undo log主要记录了数据的逻辑变化，比如一条INSERT语句，对应一条DELETE的undo log，对于每个UPDATE语句，对应一条相反的UPDATE的undo log，这样在发生错误时，就能回滚到事务之前的数据状态。

同时，undo log也是MVCC(多版本并发控制)实现的关键
四、主从复制的原理
1.什么是主从复制?

 主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

2.主从复制的作用

 1、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
 2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
 3、读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

3.主从复制的原理

 数据库有个bin-log二进制文件，记录了所有sql语句。
 我们的目标就是把主数据库的bin-log文件的sql语句复制过来。
 让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。
 下面的主从配置就是围绕这个原理配置
 具体需要三个线程来操作：
binlog输出线程:每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。

在从库里，当复制开始的时候，从库就会创建两个线程进行处理：

从库I/O线程:当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。
从库的SQL线程:从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。

可以知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。



4.总结

步骤一：主库db的更新事件(update、insert、delete)被写到binlog
步骤二：从库发起连接，连接到主库
步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库
步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.
步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db.

一 什么是主从复制
主从复制是用来建立与主数据完全的一样数据库环境，称为从数据库。主数据库一般是准实时的业务数据库。
二 主从复制的作用（好处或者为什么要使用主从复制）
做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
三 主从复制的原理（重中之重，面试必问）：
数据库有个bin-log二进制文件，记录了所有sql语句。

我们的目标就是把主数据库的bin-log文件的sql语句复制过来。

让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。

下面的主从配置就是围绕这个原理配置

具体需要三个线程来操作：

binlog输出线程:每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。在从库里，当复制开始的时候，从库就会创建两个线程进行处理：
从库I/O线程:当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。
从库的SQL线程:从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。
可以知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。
主从复制如图



原理图2,帮助理解!


步骤一：主库db的更新事件(update、insert、delete)被写到binlog

步骤二：从库发起连接，连接到主库

步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库

步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.

步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db.
四 mysql主从复制存在的问题：
主库宕机后，数据可能丢失

从库只有一个sql Thread，主库写压力大，复制很可能延时

解决方法：

半同步复制—解决数据丢失的问题

并行复制—-解决从库复制延迟的问题

1、什么是主从复制
1、主从的作用
2、主从的原理
3、从数据库的读的延迟问题了解吗？如何解决？
4、做主从后主服务器挂了怎么办？
一、什么是主从复制?
主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。
二、主从复制的作用(好处，或者说为什么要做主从)重点!
1、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，物理服务器增加，负荷增加。
2、读写分离，使数据库能支撑更大的并发。主从只负责各自的写和读，极大程度的缓解X锁和S锁争用。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
3、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
三、主从复制的原理(重中之重)：
1.数据库有个bin-log二进制文件，记录了所有sql语句。
2.我们的目标就是把主数据库的bin-log文件的sql语句复制过来。
3.让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。
4.下面的主从配置就是围绕这个原理配置
5.具体需要三个线程来操作：
1.binlog输出线程:每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。
在从库里，当复制开始的时候，从库就会创建两个线程进行处理：
2.从库I/O线程:当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。
3.从库的SQL线程:从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。
可以知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。
主从复制如图：
原理图2,帮助理解!
步骤一：主库db的更新事件(update、insert、delete)被写到binlog
步骤二：从库发起连接，连接到主库
步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库
步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.
步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db.
四、从数据库的读的延迟问题了解吗？如何解决？
原因：当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待，还有网络延迟。(谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高；slave的Slave_IO_Running线程会到主库取日志，效率会比较高，slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施。DML和DDL的IO操作是随机的，不是顺序的，因此成本会很高，还可能是slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。)
解决方法一：最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
解决方法二：数据放入缓存中，更新数据库后，在预期可能马上用到的情况下，主动刷新缓存。
解决办法三：对于比较重要且必须实时的数据，比如用户刚换密码(密码写入 Master)，然后用新密码登录(从 Slaves 读取密码)，会造成密码不一致，导致用户短时间内登录出错。所以在这种需要读取实时数据的时候最好从 Master 直接读取，避免 Slaves 数据滞后现象发生。
五：做主从后主服务器挂了怎么办？
假设发生了突发事件，master宕机，现在的需求是要将192.168.1.102提升为主库，另外一个为从库
步骤：
1.确保所有的relay log全部更新完毕，在每个从库上执行stop slave io_thread; show processlist;直到看到Has read all relay log,则表
示从库更新都执行完毕了
2.登陆所有从库，查看master.info文件，对比选择pos最大的作为新的主库，这里我们选择192.168.1.102为新的主库
3.登陆192.168.1.102，执行stop slave; 并进入数据库目录，删除master.info和relay-log.info文件, 配置my.cnf文件，开启log-bin,如果有
log-slaves-updates和read-only则要注释掉，执行reset master
4.创建用于同步的用户并授权slave，同第五大步骤
5.登录另外一台从库，执行stop slave停止同步
6.根据第七大步骤连接到新的主库
7.执行start slave;
8.修改新的master数据，测试slave是否同步更新
读写分离实现方法：
为了减轻数据库的压力，一般会进行数据库的读写分离，实现方法一是通过分析sql语句是insert/select/update/delete中的哪一种，从而对应选择主从，二是通过拦截方法名称的方式来决定主从的，如：save*()、insert*() 形式的方法使用master库，select()开头的使用slave库。
虽然大多数都是从程序里直接实现读写分离的，但对于分布式的部署和水平和垂直分割，一些代理的类似中间件的软件还是挺实用的，如 MySQL Proxy比较。mysql proxy根本没有配置文件， lua脚本就是它的全部，当然lua是相当方便的。
六：innodb_flush_log_at_trx_commit 和 sync_binlog
innodb_flush_log_at_trx_commit 和 sync_binlog 是 MySQL 的两个配置参数。它们的配置对于 MySQL 的性能有很大影响(一般为了保证数据的不丢失，会设置为双1，该情形下数据库的性能也是最低的)。
1、innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit：是 InnoDB 引擎特有的，ib_logfile的刷新方式( ib_logfile：记录的是redo log和undo log的信息)
取值:0/1/2
innodb_flush_log_at_trx_commit=0，表示每隔一秒把log buffer刷到文件系统中(os buffer)去，并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。也就是说一秒之前的日志都保存在日志缓冲区，也就是内存上，如果机器宕掉，可能丢失1秒的事务数据。
innodb_flush_log_at_trx_commit=1，表示在每次事务提交的时候，都把log buffer刷到文件系统中(os buffer)去，并且调用文件系统的“flush”操作将缓存刷新到磁盘上去。这样的话，数据库对IO的要求就非常高了，如果底层的硬件提供的IOPS比较差，那么MySQL数据库的并发很快就会由于硬件IO的问题而无法提升。
innodb_flush_log_at_trx_commit=2，表示在每次事务提交的时候会把log buffer刷到文件系统中去，但并不会立即刷写到磁盘。如果只是MySQL数据库挂掉了，由于文件系统没有问题，那么对应的事务数据并没有丢失。只有在数据库所在的主机操作系统损坏或者突然掉电的情况下，数据库的事务数据可能丢失1秒之类的事务数据。这样的好处，减少了事务数据丢失的概率，而对底层硬件的IO要求也没有那么高(log buffer写到文件系统中，一般只是从log buffer的内存转移的文件系统的内存缓存中，对底层IO没有压力)。
2、sync_binlog
sync_binlog：是MySQL 的二进制日志(binary log)同步到磁盘的频率。
取值：0-N
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。这个是性能最好的。
sync_binlog=1，当每进行1次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
注：
大多数情况下，对数据的一致性并没有很严格的要求，所以并不会把 sync_binlog 配置成 1. 为了追求高并发，提升性能，可以设置为 100 或直接用 0.
而和 innodb_flush_log_at_trx_commit 一样，对于支付服务这样的应用，还是比较推荐 sync_binlog = 1.