我们知道应用对数据库的訪问通常情况下大部分都是读操作，写仅仅占非常少一部分。因此读写分离(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.log

server-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从主库中读取数据，这也是一种能够接受的方案。

配置演示样例：