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