全部博文（533）
分类： LINUX
2011-03-31 11:40:00
一、环境描述
服务器A 192.168.1.108
服务器B 192.168.1.110
Mysql版本：5.1.26
System OS：CentOS release 5.4
二、主主配置过程
1、创建同步用户：
服务器A：
grant replication slave,file on *.* to 'replication'@'192.168.1.110' identified by '123456';
flush privileges;
服务器B：
grant replication slave,file on *.* to 'replication'@'192.168.1.108' identified by '123456';
flush privileges;
2、修改mysql配置文件
A：
log-bin=mysql-bin
server-id = 1
binlog-do-db=test
binlog-ignore-db=mysql
replicate-do-db=test
replicate-ignore-db=mysql
log-slave-updates
slave-skip-errors=all
sync_binlog=1
auto_increment_increment=2
auto_increment_offset=1
B：
log-bin=mysql-bin
server-id = 2
binlog-do-db=test
binlog-ignore-db=mysql
replicate-do-db=test
replicate-ignore-db=mysql
log-slave-updates
slave-skip-errors=all
sync_binlog=1
auto_increment_increment=2
auto_increment_offset=2
3、重启mysql服务后，进入mysql命令行，执行操作如下：
A:
mysql> flush tables with read lock;
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000028
Position: 866
Binlog_Do_DB: test
Binlog_Ignore_DB: mysql
1 row in set (0.00 sec)
mysql> unlock tables;
mysql> stop slave;
mysql> change master to master_host='192.168.1.110',master_user='replication',master_password='123456',master_log_file='mysql-bin.000014', master_log_pos=704;
mysql> start slave;
B：
mysql> flush tables with read lock;
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000014
Position: 704
Binlog_Do_DB: test
Binlog_Ignore_DB: mysql
1 row in set (0.00 sec)
mysql> unlock tables;
mysql> stop slave;
mysql> change master to master_host='192.168.1.108',master_user='replication',master_password='123456',master_log_file='mysql-bin.000028', master_log_pos=866;
mysql> start slave;
4、查看各服务器的状态：
mysql> show slave status\G;
出现：Slave_IO_Running: Yes
Slave_SQL_Running: Yes
则状态正常，直接测试数据能否同步就OK了！
13.4 Replication 搭建实现
MySQL Replication环境的搭建实现比较简单，总的来说其实就是四步，第一步是做好Master 端的准备工作。第二步是取得 Master 端数据的“快照”备份。第三步则是在 Slave 端恢复 Master 的备份“快照”。第四步就是在 Slave 端设置 Master 相关配置，然后启动复制。在这一节中，并不是列举一个搭建 Replication 环境的详细过程，因为这在 MySQL官方操作手册中已经有较为详细的描述了，我主要是针对搭建环境中几个主要的操作步骤中可以使用的各种实现方法的介绍，下面我们针对这四步操作及需要注意的地方进行一个简单的分析。
1. Master 端准备工作
在搭建 Replication 环境之前，首先要保证 Master 端 MySQL 记录 Binary Log 的选项打开，因为 MySQL Replication 就是通过 Binary Log 来实现的。让 Master 端 MySQL 记录 Binary Log 可以在启动 MySQL Server 的时候使用 —log-bin 选项或者在 MySQL 的配置文件 my.cnf 中配置 log-bin[=path for binary log]参数选项。
在开启了记录 Binary Log 功能之后，我们还需要准备一个用于复制的 MySQL 用户。可以通过给一个现有帐户授予复制相关的权限，也可以创建一个全新的专用于复制的帐户。当然，我还是建议用一个专用于复制的帐户来进行复制。在之前“MySQL 安全管理”部分也已经介绍过了，通过特定的帐户处理特定一类的工作，不论是在安全策略方面更有利，对于维护来说也有更大的便利性。实现 MySQL Replication 仅仅只需要“REPLICATION SLAVE” 权限即可。可以通过如下方式来创建这个用户：
root@localhost : mysql 04:16:18> CREATE USER 'repl'@'192.168.0.2'
-> IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.00 sec)
root@localhost : mysql 04:16:34> GRANT REPLICATION SLAVE ON *.*
-> TO 'repl'@'192.168.0.2';
Query OK, 0 rows affected (0.00 sec)
这里首先通过 CREATE USER 命令创建了一个仅仅具有最基本权限的用户 repl，然后再通过 GRANT 命令授予该用户 REPLICATION SLAVE 的权限。当然，我们也可以仅仅执行上面的第二条命令，即可创建出我们所需的用户，这已经在“MySQL 安全管理”部分介绍过了。
2. 获取 Master 端的备份“快照”
这里所说的 Master 端的备份“快照”，并不是特指通过类似 LVM 之类的软件所做的 snapshot，而是所有数据均是基于某一特定时刻的，数据完整性和一致性都可以得到保证的备份集。同时还需要取得该备份集时刻所对应的 Master 端 Binary Log 的准确 Log Position，因为在后面配置 Slave 的时候会用到。
一般来说，我们可以通过如下集中办法获得一个具有一致性和完整性的备份集以及所对应的 Log Position：
◆ 通过数据库全库冷备份
对于可以停机的数据库，我们可以通过关闭 Master 端 MySQL，然后通过 copy 所有数据文件和日志文件到需要搭建 Slave 的主机中合适的位置，这样所得到的备份集是最完整的。在做完备份之后，然后再启动 Master 端的 MySQL。
当然，这样我们还仅仅只是得到了一个满足要求的备份集，我们还需要这个备份集所对应的日志位置才能可以。对于这样的备份集，我们有多种方法可以获取到对应的日志位置。如在 Master 刚刚启动之后，还没有应用程序连接上 Master 之前，通过执行 SHOW Master STATUS 命令从 Master端获取到我们可以使用的 Log Position。如果我们无法在 Master 启动之后控制应用程序的连接，那么可能在我们还没有来得及执行 SHOW Master STATUS 命令之前就已经有数据写进来了，这时候我们可以通过 mysqlbinlog 客户端程序分析 Master 最新的一个 Binary Log来获取其第一个有效的 Log Position。当然，如果你非常清楚你所使用的 MySQL 版本每一个新的 Binary Log 第一个有效的日志位置，自然就不需要进行任何操作就可以。
◆ 通过 LVM 或者 ZFS 等具有 snapshot 功能的软件进行“热备份”
如果我们的 Master 是一个需要满足 365 * 24 * 7 服务的数据库，那么我们就无法通过进行冷备份来获取所需要的备份集。这时候，如果我们的 MySQL 运行在支持 Snapshot 功能的文件系统上面（如 ZFS），或者我们的文件系统虽然不支持 Snapshot，但是我们的文件系统运行在 LVM 上面，那么我们都可以通过相关的命令对 MySQL 的数据文件和日志文件所在的目录就做一个 Snapshot，这样就可以得到了一个基本和全库冷备差不多的备份集。
当然，为了保证我们的备份集数据能够完整且一致，我们需要在进行Snapshot过程中通过相关命令（FLUSH TABLES WITH READ LOCK）来锁住所有表的写操作，也包括支持事务的存储引擎中commit动作，这样才能真正保证该 Snapshot的所有数据都完整一致。在做完 Snapshot 之后，我们就可以 UNLOCK TABLES 了。可能有些人会担心，如果锁住了所有的写操作，那我们的应用不是就无法提供写服务了么？确实，这是无法避免的，不过，一般来说 Snapshot 操作所需要的时间大都比较短，所以不会影响太长时间。
那 Log Position 怎么办呢？是的，通过 Snapshot 所做的备份，同样需要一个该备份所对应的 Log Position 才能满足搭建 Replication 环境的要求。不过，这种方式下，我们可以比进行冷备份更容易获取到对应的 Log Position。因为从我们锁定了所有表的写入操作开始到解锁之前，数据库不能进行任何写入操作，这个时间段之内任何时候通过执行 SHOW MASTER STATUS 明令都可以得到准确的 Log Position。
由于这种方式在实施过程中并不需要完全停掉 Master 来进行，仅仅只需要停止写入才做，所以我们也可以称之为“热备份”。
◆ 通过 mysqldump 客户端程序
如果我们的数据库不能停机进行冷备份，而且 MySQL 也没有运行在可以进行 Snapshot 的文件系统或者管理软件之上，那么我们就需要通过 mysqldump 工具来将 Master 端需要复制的数据库（或者表）的数据 dump 出来。为了让我们的备份集具有一致性和完整性，我们必须让 dump 数据的这个过程处于同一个事务中，或者锁住所有需要复制的表的写操作。要做到这一点，如果我们使用的是支持事务的存储引擎（如 Innodb），我们可以在执行 mysqldump 程序的时候通过添加 —single-transaction 选项来做到，但是如果我们的存储引擎并不支持事务，或者是需要 dump 表仅仅只有部分支持事务的时候，我们就只能先通过 FLUSH TABLES WITH READ LOCK 命令来暂停所有写入服务，然后再 dump 数据。当然，如果我们仅仅只需要 dump 一个表的数据，就不需要这么麻烦了，因为 mysqldump 程序在 dump 数据的时候实际上就是每个表通过一条 SQL 来得到数据的，所以单个表的时候总是可以保证所取数据的一致性的。
上面的操作我们还只是获得了合适的备份集，还没有该备份集所对应的 Log Position，所以还不能完全满足搭建 Slave 的要求。幸好 mysqldump 程序的开发者早就考虑到这个问题了，所以给 mysqldump 程序增加了另外一个参数选项来帮助我们获取到对应的 Log Position，这个参数选项就是 —master-data 。当我们添加这个参数选项之后，mysqldump会在 dump 文件中产生一条 CHANGE MASTER TO 命令，命令中记录了 dump时刻所对应的详细的 Log Position 信息。如下：
测试 dump example 数据库下的 group_message 表：
sky@sky:~$ mysqldump --master-data -usky -p example group_message > group_message.sql
Enter password:
然后通过 grep 命令来查找一下看看：
sky@sky:~$ grep "CHANGE MASTER" group_message.sql
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000035', MASTER_LOG_POS=399;
连 CHANGE MASTER TO 的命令都已经给我们准备好了，还真够体贴的，呵呵。
