复制和备份

复制

• 复制的目的是让一台服务器的数据和其他服务器保持同步
• 复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但是可以用于备份和从崩溃中恢复，这点开销是必要的
• 每个备库都会对主库增加一些负载，主要是从主库读取二进制文件的开销
• 对于写操作，在一主多从的情况下，写操作会被执行多次，系统的性能就取决于最慢的部分，而且一主多从，会有很多重复数据，可能会造成浪费

复制的基本原则：

• 一个从库只能有一个主库，一个主库可以有多个从库
• 每个从库必须有一个唯一的服务器id，如果有重复的ID，会相互竞争，把对方从主库上踢出
• 如果打开了log_slave_updates，从库可以成为其他库的主库

复制解决的主要问题有：

• 可以在不同地理位置分布数据备份，避免单点故障，容灾

• 可以将读操作负载均衡到多个服务器上

• 读写分离

  • 复制产生了多个数据副本，由于从库的复制是异步的，所以难点是在如何处理从库上的脏数据
  • 读写分离的实现方式：
    • 最简单的方法就是把所有不能容忍脏数据的sql分配到主库，其他的查询分配到从库，虽然很容易实现，但是很少有查询可以允许脏数据
    • 也可以让应用检查复制的延迟，不需要从库百分比更上主库，如果数据很老，就从主库获取
    • 也可以基于版本号、时间戳等，来判断数据是否足够新

复制的步骤

• 首先是主库在每次准备提交事务完成数据更新前，会将数据更新的事件按照事务的提交顺序记录到二进制日志中，然后才提交事务
• 而从库会启动一个工作线程跟主库建立一个普通的客户端连接，然后在主库上启动一个二进制转储线程读取主库上的二进制日志中的事件，然后把主库上的日志复制到自己的中继日志中，如果这个线程追赶上了主库，就会进入休眠状态，直到主库通知有新的事件产生才会唤醒
• 最后从库会读取中继日志中的事件，在从库执行
• 这种复制架构，实现了获取事件和重放事件的解耦，允许两个过程异步执行，但是也限制了复制的过程，主库并发运行的sql，在从库上只能串行化执行，因为只有一个线程来重放中继日志中的事件

mysql复制的方式有：基于行的复制和基于语句的复制

• 基于行的复制

  • 这种方式会把实际数据记录在二进制日志中，好处就是能正确复制每一行，没有无法处理的场景，而且不需要重新执行sql语句，可以更加高效的复制数据，特别是对大表的数据汇总到小表
  • 但是如果遇到对全部数据进行更新的sql，基于行的复制，开销会非常大，因为每一行都会被记录到二进制日志
  • 而且因为语句没有记录在日志里，就无法判断执行了那些sql，如果出现问题，会很难排查

• 基于语句的复制

  • 主库会记录那些造成数据更改的sql，然后从库读取重放，也就是把主库执行过的sql在执行一遍
  • 好处是实现简单，而且二进制日志里的事件紧凑，不会带来太多网络开销
  • 缺点是sql可能包含不确定的函数，例如时间戳，存储过程和触发器都有可能出现问题
  • 此外，更新必须是串行的，因为sql语句的顺序不能改变

• 两种模式都有优缺点，mysql可以自动在两种模式间切换，默认使用的是基于语句的复制，但是如果发现语句无法被正确复制，就会使用基于行的模式

• 两种方式也都是通过在主库上记录二进制日志，在备库重放日志的方式来实现异步的数据复制，所以同一时间点主库和从库的数据可能不一致，而且无法保证主从之间的延迟

• 可以使用高版本的mysql作为低版本的从库，但是低版本最好不要作为高版本的从库

复制过滤器：

• 运行值复制服务器上一部分数据，有两种过滤方式，一种是过滤主库到二进制日志的事件，一种是在从库上过滤记录到中继日志的事件
• 通常不要开启，否则会造成数据的永久丢失，并且无法找回，很容易造成主备不同步或者复制出错

复制配置：

• sync_binlog=1，开启之后，提交事务前，会将二进制日志同步到磁盘上，保证服务器崩溃时不会丢失事件，一般只在主库开启，对于从库来说是额外的开销
• log_slave_updates，可以让备库变为其他服务器的主库，设置之后，mysql会把自己执行的事件记录到二进制日志中

常见的配置：

• 一主多备：

  • 和一主一备，配置差不多，因为从库间没有交互，仅仅是连接到同一个主库
  • 少量写大量读时，这种配置非常有效，可以把读分配到多个从库上
  • 可以用作灾难恢复，也可以拿一个从库作为测试环境

• 主动-主动模式

  • 也叫双向复制，两台服务器，互为对方的主库，例如两个不同地理位置的办公室，都需要一份可写的数据拷贝
  • 最大的问题是如何解决冲突，带来的麻烦远大于好处
  • mysql，不支持多主库间的复制

• 主动-被动模式

  • 其中的一台服务器是只读的被动服务器
  • 因为服务器的配置对称，所以故障转移和故障恢复很容易

• 环形复制

  • 三个或以上的服务器，相互复制，形成一个环形链，整个结构非常脆弱，应该尽量避免

• 主库-分发主库-从库

  • 一个主库，一个分发主库，分发主库用来将二进制日志分发多个从库，减小了主库的负担

备份

备份的理由：

• 灾难恢复
• 需要知道过去某个点的数据是什么样的
• 再进行某些操作后，又想恢复
• 对于大数据库来说，物理备份是必须的，逻辑备份慢，而且恢复需要很长时间

关闭系统做离线备份，是最简单也是最安全的，数据损坏和不一致的风险也最小，但是让服务器停机的代价可能会很高，所以必须要使用不停机备份

mysql的备份方式

• 逻辑备份也叫导出

  • 优点
    • 逻辑备份导出的文件可以通过工具直接查看内容
    • 恢复数据也很简单，导入就可以了
    • 和存储引擎没有关系，因为是从mysql服务器中提取出来的数据
    • 有助于避免数据损坏，不会因为磁盘损坏导出一份错误的数据
  • 缺点
    • 必须由服务器完成生成逻辑备份的工作，会增加cpu负载
    • 逻辑备份可能比数据库文件更大
    • 无法保证导出后再还原是一样的数据，例如浮点数
    • 从逻辑备份中还原需要mysql加载和解释语句，并且重建索引，会比较漫长

• 物理备份是直接复制原始文件

  • 优点
    • 只需要复制文件，没有其他额外操作
    • 恢复会更快，因为mysql服务器不需要执行任何sql或者构建索引
  • 缺点
    • innodb的原始文件比逻辑备份大很多
    • 物理备份不一定可以跨平台