谈谈 MySQL 的主从

2016/04/01 MySQL

关于主从复制的一些认识。

背景

最近面试了一批人,几乎没有一个可以把 MySQL 的主从讲的非常清楚,最多只是把网上关于MySQL主从的文章复述一遍,当问到一些开放性的问题的时候便无能为力或者顾左右而言他。

主从的原理

MySQL 的主从其实并不复杂,MySQL 的主从其本质也不过是一个 C/S 架构的应用,本身并没有什么复杂的地方。无非是主库把事务记入日志,而从库则读取这些日志并且重做这些事务。一路面试下来,很多人对这些内部的原理所知甚少,对于主从的理解基本上还停留在配置层面,无非是一些按步骤操作的过程而已。

主从配置方面需要注意的问题

关于主库导出的问题

mysqldump 导出数据比较慢,如果是小批量的数据导出可以使用这种方法,但是大批量数据导出的话,就不可以使用这种方法。并且,在处理 myisam 表的时候,是需要锁表的。生产环境一般数据量都比较大,一般不太建议使用 mysqldump 导出的方式。所以一般我们会选用 percona 提供的 xtrabackup 这种备份工具先做一个完整的物理备份,然后再配置主从。

影响日志的两个参数

  • 参数

    sync_binlog innodb_flush_logs_at_trx_commit

innodb_flush_logs_at_trx_commit 可选项为 0,1,2 , 安全级别为 0 < 2 < 1 。默认为 1,每进行一次事务,就刷新一次日志。为 2 时,在每个事务提交时,日志缓冲被写到文件,但不对日志文件做到磁盘操作的刷新。为 0 时,日志缓冲每秒一次被写到日志文件,并且对日志文件做到磁盘操作的刷新。但任何 mysqld 的进程崩溃会删除崩溃前最后一秒的事务。

sync_binlog=N 可选项为N>=0N=0 时不主动刷新二进制日志文件到磁盘上,而是由操作系统决定。N>0 每向二进制日志写入N条SQL或N个事务后,则把二进制日志数据刷新到磁盘上。

如果在磁盘性能足够好的情况下,推荐把以上两个参数都设置为 1 ,这样安全性非常好,可以保证准备数据是一致的。

关于级联复制从库需要注意的参数

  • 从库上需要打开的两个参数

    log-slave-updates log-bin

如果开启级联复制 A->B->C 此时,B 作为 A 的从库,作为 C 的主库,此时需要在 B 上把以上两个参数打开,确保级联复制可以顺利进行。

参考链接

从库的权限方面的问题

  • 从库的权限相关参数

    read_only # 除复制用户和superuser 外,其它用户均为只读用户 super_read_only # 即使是超级用户也只是只读用户

关于部分复制的问题

有时候,我们只想在 Master 上复制一个库,或者说,有些库的改变,我们并不希望复制到从库上来,这时候,有几个参数是需要关注的。

  • 在从库上配置的选项

    replicate-do-db # 需要复制的数据库名,如果需要复制多个库,可以重复设置这个选项 replicate-ignore-db # 需要忽略的数据库名,如果忽略多个库,可以重复设置这个选项

  • 在主库上配置的选项

    binlog-do-db # 需要记录日志的数据库名,如果有多个库,重复设置这个选项即可 binlog-ignore-db # 需要忽略的数据库名,如果有多个,可重复设置这个选项

事实上,do 和 ignore 配置一项就可以了。通常的做法是在主库上用 ignore ,在从库上用 do 。在主库上使用 binlog-ignore-db 忽略掉我们不想复制的库,比如说 mysql 这个库。在从库上使用 replicate-do-db 仅仅复制我们希望复制的数据库。

Search

    Table of Contents