Mysql主从数据库(master/slave)，实现读写分离

在之前的一篇文章中，阐述了如何在高并发高负载的场景下使用nginx做后台服务的负载均衡:在阿里云Centos上配置nginx+uwsgi+负载均衡配置,但是不要以为这样做了就是一劳永逸的，到了数据业务层、数据访问层，如果还是传统的数据结构，或者只是单单靠一台服务器负载，如此多的数据库连接操作，数据库必然会崩溃，数据库如果宕机的话，后果更是不堪设想。这时候，我们会考虑如何减少数据库的连接，一方面采用优秀的代码框架，进行代码的优化，采用优秀的数据缓存技术如：redis,如果资金丰厚的话，必然会想到架设mysql服务集群，来分担主数据库的压力。今天总结一下利用MySQL主从配置，实现读写分离，减轻数据库压力。

明确目的，部署mysql集群，采用一主一从的策略，写入操作使用主库，从库实时同步主库的数据，从库负责读取的业务，从而完成读写分离的目的。

mysql主从同步的原理很简单，从库生成两个线程，一个I/O线程，一个SQL线程；i/o线程去请求主库 的binlog（二进制日志），并将得到的binlog日志写到relay log（中继日志） 文件中；主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；

SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致。

首先准备两台阿里云服务器，一台作为主机(master)，一台作为从机(slave)，都安装好mysql5.7

进入master服务器

修改mysql配置文件 vim /etc/my.cnf，加入如下配置

server-id=1
innodb_flush_log_at_trx_commit=2
sync_binlog=1
log-bin=mysql-bin-1

配置说明：

#设置主服务 的ID (id可以自己随便设置但是要保证和slave的id不一样)
server-id=1

#设为1当然是最安全的，但性能也是最差的（相对其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2，如果只最求性能，例如高并发写的日志服务器，设为0来获得更高性能
innodb_flush_log_at_trx_commit=2

#开启binlog 志同步功能
sync_binlog=1 

#binlog 日志文件名
log-bin=mysql-bin-200 

# 这个表示只同步某个库 (如果没有此项，表示同步所有的库)
binlog-do-db=xxxx

保存后，重启mysql

systemctl restart mysqld

进入mysql命令行 mysql -uroot -p你的密码

输入授权命令

GRANT REPLICATION SLAVE ON *.* to 'repl'@'%' identified by 'Admin123!'; 

意思是所有slave都可以通过账号repl和密码Admin123!来同步master的数据

然后查看master的状态:

show master status;

此时Master的配置已经搞定，登录一下从机(slave)

同理修改slave服务器的mysql配置 vim /etc/my.cnf 加入下面的配置，需要注意的是server-id不要和master一样

server-id=201
innodb_flush_log_at_trx_commit=2
sync_binlog=1
log-bin=mysql-bin-201

保存后重启服务 systemctl restart mysqld

进入mysql命令行 mysql -uroot -p你的密码

输入命令：

change master to master_host='39.106.228.179',master_user='repl' ,master_password='Admin123!', master_log_file='mysql-bin.000002' ,master_log_pos=154

命令说明：

master_host: 主机的ip

master_user : 主机授权的用户.

master_password : 主机授权时候填写的密码

master_log_file : 主机show master status;中的File

master_log_pos: 主机show master status;中的Position.

输入命令启动slave

start slave;

然后我们就可以测试一下对master进行写入，看看salve是否可以同步数据了

当然了，mysql的读写分离主从配置并不是万能的，根据不同的应用场景选择不同的策略，MySQL的主从复制功能有一定的延迟性，如果对数据实时一致性的要求比较高的场景不推荐使用。