我们知道应用对数据库的訪问通常情况下大部分都是读操作，写仅仅占非常少一部分。因此读写分离(read-write-splitting)能有效减少主库压力，从而解决站点发展过程中遇到的第一次数据库瓶颈。
主从复制
首先必须开启master库的bin-log，由于mysql的主从复制是异步的。所以master库必须将更新操作记录下来以供slave库读取。
假设如今有A, B两台机器，A为master, B为slave。Master
ssh至A服务器，登陆mysql, 创建一个复制专用用户repl：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'B的IP' IDENTIFIED BY '111111';
改动my.cnf文件。开启bin-log并设置server-id：
[mysqld]log-bin = /XXXX/mysql-bin.logserver-id = 1
重新启动mysql使配置生效。
然后设置读锁，确保在配置好slave库之前master库没有读写操作：
flush tables with read lock;
查看master库当前bin-log的文件名称和偏移量：
show master status;+------------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000002 | 1075 | | |+------------------+----------+--------------+------------------+1 row in set (0.00 sec)
记下文件名称和偏移量。此时master已经停止了全部的数据更新操作，这时候我们要把master库的数据进行备份，然后还原到slave库中。推荐通过mysqldump命令完毕该操作。master备份完毕后就可以取消锁：
unlock tables;
Slave
ssh至B服务器，改动配置文件：
[mysqld]server-id = 2
通过mysqld_safe启动从库。加入--skip-slave-start參数：
mysqld_safe --skip-slave-start
这样做的目的是不要让从库启动时就启动复制线程。由于我们还没有配置主库信息。
mysql> CHANGE MASTER TO-> MASTER_HOST='主库地址',-> MASTER_PORT=3306,-> MASTER_USER='repl',-> MASTER_PASSWORD='111111',-> MASTER_LOG_FILE='mysql-bin.000002', -> MASTER_LOG_POS=1075;
启动slave线程：
start slave;
至此从库配置完毕。假设一切顺利的话，此时在主库运行一条更新操作，从库也会立即跟进。
假设发现有问题，能够运行
show slave status;
查看具体信息。
读写分离
眼下读写分离有两种方案：
- 控制应用程序，写操作连接主库，读操作连接从库。
- 引入数据库中间件。如官方的
mysql-proxy。优点是读写分离相应用程序全然透明，不须要对程序代码做不论什么改动。
可是眼下
mysql-proxy依旧仅仅有alpha版本号，而且官方也不推荐将其用在生产环境中。
事实上对于方案一另一个比較优雅的解决方式。那就是使用ReplicationDriver。
MySQL的JDBC驱动中自带ReplicationDriver。它能够将JDBC中全部conn.setReadOnly(true)的连接路由到从库中，从而使得我们不必对程序代码动大手术。
配合Spring, 我们能够使用@Transactional(readOnly = true)注解。
由于MySQL主从复制有延迟，所以对于实时性要求高的操作，我们能够将readOnly设为false来让ReplicationDriver从主库中读取数据，这也是一种能够接受的方案。
配置演示样例：