CentOS 6.5 下MySQL 5.7.12主从复制架构配置记录

为什么使用主从架构？

1、实现服务器负载均衡；

2、通过复制实现数据的异地备份；

3、提高数据库系统的可用性；

4、可以分库【垂直拆分】，分表【水平拆分】；

主从配置的前提条件

1、MySQL版本一致；

你还没有安装MySQL？

请参考：CentOS 6.5 下安装MySQL 5.7.12，使用官网下载的rpm安装包

2、MySQL中的数据一致；

不一致就把它们搞一致！

3、操作前停止一切更新操作（写入、更新、删除等）；

配置master（主服务器）

vi /etc/my.cnf
#[必须]启用二进制日志
log-bin=mysql-bin
#[必须]服务器唯一ID，默认是1，一般取IP最后一段
server-id=151

配置slave（从服务器）

vi /etc/my.cnf
#[可选]启用二进制日志
log-bin=mysql-bin
#[必须]服务器唯一ID，默认是1，一般取IP最后一段
server-id=152

如果你的从服务器下面再挂从服务器，启用二进制日志就是必选的！

重启mysql服务

/etc/init.d/mysqld restart

重启的目的是使用刚才的配置生效，主从都需要重启；

注意：服务名是“mysqld”，不是某同学文章中的“mysql”！

在主服务器上创建备份专用帐户

mysql -uroot -ppassword -e "GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO 'backup'@'192.168.0.154' IDENTIFIED BY '123456';"

注意：

1、这里是用GRANT创建用户并授权远程登录权限，而不是使用“Create User”来创建；

2、命令是在Shell下执行，不是在“mysql”客户端中执行；

我是为了方便，直接把命令都写到一行里了，当然你也可以先用“mysql -uroot -ppassword”登录后，

再执行“GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO 'backup'@'192.168.0.154' IDENTIFIED BY '123456';”；

命令中的“password”是什么鬼？我怎么登录不了！泥玛，我哪知道你的 root 用户密码是什么鬼！

查询master(主服务器)的状态

mysql -uroot -ppassword -e "show master status;"

这是在主服务器上执行的，看准了。

不解释了，看输出：

mysql: [Warning] Using a password on the command line interface can be insecure.
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+

File列和Position列的值一会儿我们要用到。

配置Slave启动主从复制

mysql -uroot -ppassword -e "change master to master_host='192.168.0.151',master_user='backup',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=154; start slave;"
//注意不要断开，154数字前后无单引号。
//启动从服务器复制功能

master_host=主服务器IP
master_user=在主服务器上创建的备份用户名
master_password=备份用户密码
master_log_file=查询master(主服务器)的状态得到的File列的值
master_log_pos=Position列的值
start slave：启动从服务器复制功能

检查从服务器复制功能状态

mysql -uroot -ppassword -e "show slave status\G;"

输出如下：

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.151
                  Master_User: backup
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 154
               Relay_Log_File: vir2-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 526
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 151
                  Master_UUID: 959de288-197f-11e6-9615-525400190a25
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

主要查看以下两项：

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Slave_IO及Slave_SQL进程必须正常运行，即YES状态，否则都是错误的状态(如：其中一个NO均属错误)。
以上操作过程，主从服务器配置完成。

我在一次配置过程中忘记在主服务器上创建备份用户，Slave_IO_Running 就一直处于“connect”状态。

主从服务器测试

在主服务器上执行以下操作：

你还是登录Mysql再操作吧，这次命令比较多，不组合了！

mysql -uroot -ppassword

create database db_test_slave;
use db_test_slave;
create table tb_test(id int(3), name varchar(50));
insert into tb_test values(1,'hello slave');
show databases;

在从服务器上执行以下操作：

mysql -uroot -ppassword -e "show databases; use db_test_slave; select * from tb_test;"

查看输出：

+--------------------+
| Database           |
+--------------------+
| information_schema |
| db_test_slave      |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
+------+-------------+
| id   | name        |
+------+-------------+
|    1 | hello slave |
+------+-------------+

看到在主服务器上创建的数据库、数据表、插入的数据记录了吗？

没有？自己找找原因吧，我一次就成功了。

结束语

上面提到了“如果你的从服务器下面再挂从服务器，启用二进制日志就是必选的！”，主从只是一个相对概念，一台MySQL服务即可以是主，也可以是从。

一开始讲了主从复制的一些好处，但是单一的主从复制也有其不足：当更新操作增加到一定程度后，主服务器的任务会过分繁重，成为瓶颈，从而使系统性能大幅度下降。另外当主机出现故障时，整个系统都涉及更新的功能都不能正常使用，因此系统的可靠性依然不高。

参考：
http://369369.blog.51cto.com/319630/790921/
http://www.cnblogs.com/Leo_wl/p/3287259.html
http://zhangfengzhe.blog.51cto.com/8855103/1563032
http://blog.csdn.net/hguisu/article/details/7325124