我们知道应用对数据库的訪问通常情况下大部分都是读操作,写仅仅占非常少一部分。因此读写分离(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从主库中读取数据,这也是一种能够接受的方案。