如何验证mysql主从复制之成功

主要是查看从机，show slave status \G 这个是查看从机复制状态，里面的参数很多，你要留意 Slave_IO_Running: Slave_SQL_Running: 这两个参数的状态，正常是YES，如果是no，那么主从复制肯定是有问题的 第一个参数是复制主库的binlog文件的线程

用 pt-table-checksum 时，会不会影响业务性能？

实验

实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。

我们先建一对主从：

然后用 mysqlslap跑一个持续的压力：

开另外一个会话，将 master 上的 general log 打开：

然后通过 pt-table-checksum 进行一次比较：

查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：

将该线程的 *** 作单独列出来：

*** 作比较多，我们一点一点来说明：

这里工具调小了 innodb 锁等待时间。使得之后的 *** 作，只要在 innodb 上稍微有锁等待，就会马上放弃 *** 作，对业务影响很小。

另外工具调小了 wait_timeout 时间，倒是没有特别的作用。

工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。

RR 级别是数据对比的基本要求。

工具通过一系列 *** 作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。

接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。

之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。

以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。

工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。

总结

本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。

还是那个观点，性能测试不能相信道听途说，得通过实验去分析。

MySQL是开源的关系型数据库系统。复制(Replication)是从一台MySQL数据库服务器（主服务器master）复制数据到另一个服务器（从服务器slave）的一个进程。

配置主服务器(master)

1、编辑数据库配置文件my.cnf,一般在/etc/目录下。

#vi /etc/my.cnf

在[mysqld]的下面加入下面代码：

log-bin=mysql-bin

server-id=1

innodb_flush_log_at_trx_commit=1

sync_binlog=1

binlog-do-db=wordpress

binlog_ignore_db=mysql

server-id=1中的1可以任定义，只要是唯一的就行。

binlog-do-db=wordpress是表示只备份wordpress。

binlog_ignore_db=mysql表示忽略备份mysql。

不加binlog-do-db和binlog_ignore_db，那就表示备份全部数据库。

2、然后重启MySQL:

#service mysqld restart

3、登录MySQL服务器。

#mysql -uroot -p

在主服务器新建一个用户赋予“REPLICATION SLAVE”的权限。你不需要再赋予其它的权限。在下面的命令，把X.X.X.X替换为从服务器的IP。

mysql>CREATE USER 'user'@ 'X.X.X.X' IDENTIFIED BY 'password'

mysql>GRANT REPLICATION SLAVE ON *.* TO 'user'@'X.X.X.X' IDENTIFIED BY 'password'

4、执行以下命令锁定数据库以防止写入数据。

mysql>FLUSH TABLES WITH READ LOCK

5、退出mysql命令行，导出数据库

#mysqldump -u root -p123456 --all-databases --lock-tables=false -- >/root/all.sql

6、使用scp命令传输数据库文件all.sql到从服务器。

#scp /root/all.sql root@www.example.com:/root

7、再次连接数据库进入mysql命令行查看master状态。

mysql>SHOW MASTER STATUS

请记下显示的信息，配置从服务器会用到。

+——————+———-+————–+——————+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+——————+———-+————–+——————+

| mysql-bin.000003 | 1001741 | dbispconfig | mysql |

+——————+———-+————–+——————+

1 row in set (0.00 sec)

8、解锁数据表。

mysql>UNLOCK TABLES

配置从服务器(slave)

登录从服务器。

1、导入主服务器的数据库。

#mysql -u root -p123456 </root/all.sql

2、编辑配置文件my.cnf,在[mysqld]下面加入：

server-id=2

2可以自己定义，只要保证唯一的就行。

3、保存文件并重启mysqld。

#service mysqld restart

4、登录mysql服务器，执行以下命令。

mysql>CHANGE MASTER TO

MASTER_HOST='X.X.X.X',

MASTER_USER='user',

MASTER_PASSWORD='password',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=98,

MASTER_CONNECT_RETRY=10

MASTER_HOST:主服务器的IP。

MASTER_USER：配置主服务器时建立的用户名

MASTER_PASSWORD：用户密码

MASTER_PORT：主服务器mysql端口，如果未曾修改，默认即可。

5、启动slave进程。

mysql>START SLAVE

6、查看mysql的日志，一般在/var/log/目录下的mysqld.log，如果启动成功，你应该会看到类似下面的日志。

[root@localhost ~]# vi /etc/my.cnf

091104 8:42:02 [Note] Slave I/O thread: connected to master ‘root@X.X.X.X:3306?, replication started in log ‘mysql-bin.000001? at position 98

现在主服务器和从服务器已经配置好了。另外你可能需要设置主服务器的数据库二进制日志的过期时间，可以在配置文件中使用参数expire_logs_days来设定。

---