CentOS 6.4系统MySQL主从复制基本配置实践

作者：

对于MySQL数据库一般用途的主从复制，可以实现数据的备份（如果希望在主节点失效后，能够使从节点自动接管，就需要更加复杂的配置，这里暂时先不考虑），如果主节点出现硬件故障，数据库服务器可以直接手动切换成备份节点（从节点），继续提供服务。基本的主从复制配置起来非常容易，这里我们做个简单的记录总结。
我们选择两台服务器来进行MySQL的主从复制实践，一台m1作为主节点，另一台nn作为从节点。
两台机器上都需要安装MySQL数据库，如果想要卸掉默认安装的，可以执行如下命令：

1 sudo rpm -e --nodeps mysql
2 yum list | grep mysql

现在可以在CentOS 6.4上直接执行如下命令进行安装：

1 sudo yum install -y mysql-server mysql mysql-deve

为root用户设置密码：

1 mysqladmin -u root password 'shiyanjun'

然后可以直接通过MySQL客户端登录：

1 mysql -u root -p

主节点配置

首先，考虑到数据库的安全，以及便于管理，我们需要在主节点m1上增加一个专用的复制用户，使得任意想要从主节点进行复制从节点都必须使用这个账号：

1 CREATE USER repli_user;
2 GRANT REPLICATION SLAVE ON *.* TO 'repli_user'@'%' IDENTIFIED BY 'shiyanjun';

这里还进行了操作授权，使用这个换用账号来执行集群复制。如果想要限制IP端段，也可以在这里进行配置授权。
然后，在主节点m1上，修改MySQL配置文件/etc/my.cnf，使其支持Master复制功能，修改后的内容如下所示：

01 [mysqld]
02 datadir=/var/lib/mysql
03 socket=/var/lib/mysql/mysql.sock
04 user=mysql
05 # Disabling symbolic-links is recommended to prevent assorted security risks
06 symbolic-links=0
07 server-id=1
08 log-bin=m-bin
09 log-bin-index=m-bin.index
10
11 [mysqld_safe]
12 log-error=/var/log/mysqld.log
13 pid-file=/var/run/mysqld/mysqld.pid

server-id指明主节点的身份，从节点通过这个server-id来识别该节点是Master节点（复制架构中的源数据库服务器节点）。
如果MySQL当前已经启动，修改完集群复制配置后需要重启服务器：

1 sudo service mysqld restart

从节点配置

接着，类似地进行从节点nn的配置，同样修改MySQL配置文件/etc/my.cnf，使其支持Slave端复制功能，修改后的内容如下所示：

01 [mysqld]
02 datadir=/var/lib/mysql
03 socket=/var/lib/mysql/mysql.sock
04 user=mysql
05 # Disabling symbolic-links is recommended to prevent assorted security risks
06 symbolic-links=0
07 server-id=2
08 relay-log=slave-relay-bin
09 relay-log-index=slave-relay-bin.index
10
11 [mysqld_safe]
12 log-error=/var/log/mysqld.log
13 pid-file=/var/run/mysqld/mysqld.pid

同样，如果MySQL当前已经启动，修改完集群复制配置后需要重启服务器：

1 sudo service mysqld restart

然后，需要使从节点nn指向主节点，并启动Slave复制，执行如下命令：

1 CHANGE MASTER TO MASTER_HOST='m1', MASTER_PORT=3306, MASTER_USER='repli_user', MASTER_PASSWORD='shiyanjun';
2 START SLAVE;

验证集群复制

这时，可以在主节点m1上执行相关操作，验证从节点nn同步复制了主节点的数据库中的内容变更。
如果此时，我们已经配置好了主从复制，那么对于主节点m1上MysQL数据库的任何变更都会复制到从节点nn上，包括建库建表、插入更新等操作，下面我们从建库开始：
在主节点m1上建库建表：

01 CREATE DATABASE workflow;
02 CREATE TABLE `workflow`.`project` (
03   `id` int(11) NOT NULL AUTO_INCREMENT,
04   `name` varchar(100) NOT NULL,
05   `type` tinyint(4) NOT NULL DEFAULT '0',
06   `description` varchar(500) DEFAULT NULL,
07   `create_at` date DEFAULT NULL,
08   `update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP,
09   `status` tinyint(4) NOT NULL DEFAULT '0',
10   PRIMARY KEY (`id`)
11 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

在m1上查看binlog内容，执行命令：

1 SHOW BINLOG EVENTS\G

binlog内容内容如下所示：

01 *************************** 1. row ***************************
02    Log_name: m-bin.000001
03         Pos: 4
04 Event_type: Format_desc
05   Server_id: 1
06 End_log_pos: 106
07        Info: Server ver: 5.1.73-log, Binlog ver: 4
08 *************************** 2. row ***************************
09    Log_name: m-bin.000001
10         Pos: 106
11 Event_type: Query
12   Server_id: 1
13 End_log_pos: 197
14        Info: CREATE DATABASE workflow
15 *************************** 3. row ***************************
16    Log_name: m-bin.000001
17         Pos: 197
18 Event_type: Query
19   Server_id: 1
20 End_log_pos: 671
21        Info: CREATE TABLE `workflow`.`project` (
22   `id` int(11) NOT NULL AUTO_INCREMENT,
23   `name` varchar(100) NOT NULL,
24   `type` tinyint(4) NOT NULL DEFAULT '0',
25   `description` varchar(500) DEFAULT NULL,
26   `create_at` date DEFAULT NULL,
27   `update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
28   `status` tinyint(4) NOT NULL DEFAULT '0',
29   PRIMARY KEY (`id`)
30 ) ENGINE=InnoDB DEFAULT CHARSET=utf8
31 3 rows in set (0.00 sec)

通过上述binlog内容，我们大概可以看到MySQL的binlog都记录那些信息，一个事件对应一行记录。这些记录信息的组织结构如下所示：

  • Log_name：日志名称，指定的记录操作的binlog日志名称，这里是m-bin.000001，与我们前面在/etc/my.cnf中配置的相对应
  • Pos：记录事件的起始位置
  • Event_type：事件类型
  • End_log_pos：记录事件的结束位置
  • Server_id：服务器标识
  • Info：事件描述信息

然后，我们可以查看在从节点nn上复制的情况。通过如下命令查看从节点nn上数据库和表的信息：

1 SHOW DATABASES;
2 USE workflow;
3 SHOW TABLES;
4 DESC project;

我们再看一下执行插入语句的情况。在主节点m1上执行如下SQL语句：

1 INSERT INTO `workflow`.`project` VALUES(1, 'Avatar-II', 1, 'Avatar-II project','2014-02-16', '2014-02-16 11:09:54', 0);

可以在从节点上执行查询，看到从节点nn上复制了主节点m1上执行的INSERT语句的记录：

1 SELECT * FROM workflow.project;

验证复制成功。

复制常用命令

下面，我们总结了几个在MySQL主从复制场景中常用到的几个相关命令：

    • 终止主节点复制
1 STOP MASTER;
    • 清除主节点复制文件
1 RESET MASTER;
    • 终止从节点复制
1 STOP SLAVE;
    • 清除从节点复制文件
1 RESET SLAVE;
    • 查看主节点复制状态
1 SHOW MASTER STATUS\G;

结果示例：

1 *************************** 1. row ***************************
2             File: m-bin.000001
3         Position: 956
4     Binlog_Do_DB:
5 Binlog_Ignore_DB:
6 1 row in set (0.00 sec)
    • 查看从节点复制状态
1 SHOW SLAVE STATUS\G;

结果示例：

01 *************************** 1. row ***************************
02                Slave_IO_State: Waiting for master to send event
03                   Master_Host: m1
04                   Master_User: repli_user
05                   Master_Port: 3306
06                 Connect_Retry: 60
07               Master_Log_File: m-bin.000001
08           Read_Master_Log_Pos: 956
09                Relay_Log_File: slave-relay-bin.000002
10                 Relay_Log_Pos: 1097
11         Relay_Master_Log_File: m-bin.000001
12              Slave_IO_Running: Yes
13             Slave_SQL_Running: Yes
14               Replicate_Do_DB:
15           Replicate_Ignore_DB:
16            Replicate_Do_Table:
17        Replicate_Ignore_Table:
18       Replicate_Wild_Do_Table:
19   Replicate_Wild_Ignore_Table:
20                    Last_Errno: 0
21                    Last_Error:
22                  Skip_Counter: 0
23           Exec_Master_Log_Pos: 956
24               Relay_Log_Space: 1252
25               Until_Condition: None
26                Until_Log_File:
27                 Until_Log_Pos: 0
28            Master_SSL_Allowed: No
29            Master_SSL_CA_File:
30            Master_SSL_CA_Path:
31               Master_SSL_Cert:
32             Master_SSL_Cipher:
33                Master_SSL_Key:
34         Seconds_Behind_Master: 0
35 Master_SSL_Verify_Server_Cert: No
36                 Last_IO_Errno: 0
37                 Last_IO_Error:
38                Last_SQL_Errno: 0
39                Last_SQL_Error:
40 1 row in set (0.00 sec)
    • 查看BINLOG列表
1 SHOW BINARY LOGS\G
Creative Commons License本文基于署名-非商业性使用-相同方式共享 4.0许可协议发布，欢迎转载、使用、重新发布，但务必保留文章署名时延军（包含链接），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请与我联系。