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

背景

最近面试了一批人，几乎没有一个可以把 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>=0。N=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 仅仅复制我们希望复制的数据库。