Mysql13 复制2

  1. 云栖社区>
  2. 博客>
  3. 正文

Mysql13 复制2

机械键盘 2015-09-14 18:07:00 浏览1163
展开阅读全文

复制管理

监控

SHOW MASTER LOGS;
查看主库当前有哪些二级制日志,其logname是其他命令的入参, file_size是偏移量也是入参。

假设我们知道日志的偏移量(来源于上面的命令)使用:
SHOW BINLOG EVENTS IN ‘mysql-bin.0000023’ FROM 13634;
能查看最后执行的sql语句。

测量备库延迟

SHOW SLAVE STATUS命令,但是会有问题:

  • 使用服务器当前日期,与二进制文件中的时间时间戳进行对别的
  • 大事件会导致延迟波动
    更好的解决办法是使用heart record.这是一个主库上会每秒更新一次的时间戳。

确认主备是否一致

pt-table-checksum检查主备是否一致的工具

从主库重新同步备库

移除备库,重新同步一个出来
使用mysqldump命令。 这个命令需要锁住表之后再操作
pt-table-sync工具

改变主库

计划内

  1. 停止写入 read only
  2. 停止客户端写入
  3. 等待备库赶上主库
  4. 将备库配置为主库
  5. 给新主库配置备库
  6. 向新主库开放访问权限

计划外
这种会面临,主库数据丢失, 不同步。 备库间也不同步

  1. 首先要确定使用那台备库,使用最新的。 SHOW SLAVE STATUS 看 Master_Log_File的值
  2. 让备库完成中继日志
  3. 导出主库的bin-log。建立空主库运行
  4. 使用SHOW MASTER STATUS查看日志位移
  5. 备库连接到临时主库继续执行位移的日志
  6. 提升备库为主库

复制问题

数据损坏或者丢失

主库意外宕机
如果没有设置sync_binlog,那么有一定的可能崩溃前几个二进制日志没有刷进磁盘。 重启之后备库线程再次连上来。主库会告诉他偏移量不存在。
解决方式是,让备库从下一个二进制日志的开头读,然后用工具查看主备一致性。 或者开启sync_binlog避免丢失,但是会带来性能损失
。。。 还有很多,具体的不赘述了

使用非事务型表

要保证主库重启前,运行了STOP SLAVE否则有可能数据不一致。

不确定语句

主要是基于语句的复制,这个开发的时候就要注意。考虑到有可能产生这种现象的原因。

使用唯一的服务器ID

InnoDB加锁读引起的锁争用

INSERT… SELECT操作会引起读锁,会使串行化。
可以拆分成小命令
使用SELECT INTO OUTFILE,, LOAD DATA INFILE代替INSERT..SELECT.更快,不加锁。

过大的复制延迟

注意,应用设计上要允许出现延迟
延迟一般都是突然出现的很不好监测

可以用些手段来提升备库的性能:

  • 发现延迟之后如果打开了log_slows_slave_statements可以查看问题
  • 关闭备库二进制日志
  • 设置刷新磁盘的点innodb_flush_log_at_trx_commit
  • 不重复写操作中代价较高的部分
    比如一个更新统计表的操作,可以优化为。在主库中新建一个库。统计结构更新这个库。然后用SELECT INTO OUTFILE和LOAD DATA INFILE来写回主库。这样就不会再备库同步执行这个操作
    基于同样的思想,还可以把这部分操作放到应用层面来做统计,然后应用层显示调用更新数据库操作。
  • 在复制之外进行操作 主要是解决了备库是串行的问题
    常见的有两种,一种是归档型数据库。归档操作进制归档操作记录到二进制文件中,然后在主库和备库上单独执行这些归档查询
    还可以对一些特殊的表单独处理。 使用应用程序手工的方式来处理这些标的同步。这样可能会带来数据性能的提升。

主备库 包大小配置不一致

如果主备的 max_allowed_packet 不匹配,有可能主库传来过大的包。 可能造成报错或者日志损坏等等。

带宽不足

可以通过开启备库的 slave_compressed_protocol选项,来让传输时对数据进行压缩及解压。

复制速度

测试:

INSERT INTO lag_test(now_usec) VALUES (NOW_USEC())
//要保证主从库时间同步
// 注意库必须是varchar列,因为时间列的精确度可能是到秒

然后使用TIMESTAMPDIFF方法来查询时间差异
可以插入1000比输入,然后根据数量级进行分组,或者求下平均值。看下一般的延迟是多久
一般情况下都是在0.几毫秒以内

一些高级特性

  • 5.1引入了行复制
  • 5.5引入了半同步。
    在提交食物后,返回给客户端结果前保证二进制日志传输到了至少一台备库上,这样就能更好的保证主从同步。但是会给客户端事务提交的时间延迟一点点。半同步还会有一点点性能改善,因为有半同步,可以更大胆的关闭bin-log。本地写磁盘转化为远程写内存。事实证明远程写内存更快。
  • 5.5还增加了复制心跳监测
  • 5.6引入了并行复制,对部分并行处理

其他复制行为

Percona Toolkit和Percona Xtrabackup都提供了基于复制或者帮助复制的功能
Tungsten Java的开源中间件复制产品。提供了自动数据分片,并发执行,数据复制,款平台复制,多源复制等功能。 他很实用,一些优点:
- 内建一致性检查
- 插件特性
- 全局事务ID,不用再去匹配日致命和偏移量了
- 能快速的将备库提升为主库
- 异构复制 比如Mysql到PostgreSQL
- 不同版本之间
- 并行
缺点则是要学习,更复杂,效率稍低。

总结一下:

  • 显著增加了Mysql的功能和可用性
  • 不提供监控,配置,管理等功能,可以使用其他管局优化,比如:Percona Toolkit和XtraBackup
  • 复制配置前需要用上面的工具来进行对比,确认是考虑
  • 监控不会落后于主库
  • 应用设计要避免主备延迟的脏数据情况
  • 备库制度并且增加权限,不要多处写。

网友评论

登录后评论
0/500
评论