使用Xtrabackup备份远端主机的MySQL实例

2015-01-12

percona Xtrabackup是一款用于MySQL备份的开源工具集, 效果类似MySQL Enterprise Backup, 支持在线备份InnoDB而不影响业务使用. 不过我一直觉得Xtrabackup是迄今为止最强悍的MySQL备份工具,没有之一.

备份的原理见: http://arstercz.com/how-innobackupex-works/

percona手册页中提供了很详细的示例来说明使用stream选项做备份: http://www.percona.com/doc/percona-xtrabackup/2.2/howtos/recipes_ibkx_stream.html

通过使用stream,再加上网络的备份方式可以很方便的以tar/gzip方式来备份非本地的机器, 不过在一些场景下, 我们只想备份一台远端机器的非压缩的备份文件, 比如要备份的机器空间不足, 或者保存备份的空间也不足(如果需要在备份主机恢复的话,至少需要2*back_size大小的磁盘空间), 这种方式不允许我们将备份保存为tar/gzip格式, 因为不够空间做解压操作.

下面的方式可以达到我们的目标, 不用解压而直接获得解压后的备份文件, 以 nc(netcat)...

Read More

追踪MySQL中长时间运行的事务

2014-12-10

https://github.com/yoshinorim/MySlowTranCapture 获取执行时间超过 milliseconds事务语句的工具;

很多时候我们需要追踪事务的执行情况以判定应用程序的操作行为, 比如启了事务, 却忘记提交而造成InnoDB事务的History List不断增大. 这是很复杂的场景, 因为很难找到一个有效的方式来识别是那种sql引起的这种问题, 追踪一个长时间运行的事务不像记录一条慢查询语句, 比如执行以下事务语句:

ysql root@[localhost:s3306 test] > begin; Query OK, 0 rows...
Read More

MySQL replication prefetch功能介绍

https://github.com/yoshinorim/replication-booster-for-mysql https://code.launchpad.net/mysql-replication-listener

主从延迟的瓶颈可能有以下几个原因:

  1. master为多线程更新, slave 的sql_thread则为单线程更新, 这意味着master大量的更新必然会引起主从延迟的持续增大;
  2. slave不对外服务的原因, buffer还未有记录相关的信息, 这造成了sql_thread在重放sql的时候要先通过磁盘IO找到相应的记录再加载到buffer进行更新, 即意味着磁盘IO造成了主从延迟的瓶颈;

第一种情况可以通过多线程的sql_thread功能实现， MySQL 5.6增加slave_parallel_workers功能以支持并行的执行events, 不过遗憾的是slave_parallel_workers是基于不同database来实现并行复制的, 如果写压力集中在一个database的几张表中, 则该参数没有本质意义的提升;也有一些第三方的补丁(比如MySQL Transfer)实现了并行执行. 第二种情况可以通过预加载行记录信息,使得行信息预先加载到buffer中, 这样sql_thread就可以更快的执行events操作....

Read More

MySQL 5.6主从故障处理说明

MySQL 5.6主从故障处理说明

5.6增加GTID特性作为主从复制的新协议, 如果开启需要指定 gtid_mode 为 on, 如果不开启主从复制采用传统的复制协议, 故障处理同5.1, 5.5. 以下讨论采用gtid协议后的故障处理;

GTID配置

http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html 与传统的复制相比, GTID去掉了文件及位置的参数信息, 改用 MASTER_AUTO_POSITION 替换.

GTID特性

http://www.percona.com/blog/2014/05/09/gtids-in-mysql-5-6-new-replication-protocol-new-ways-to-break-replication/ 明确gtid和传统方式的区别, GTID的限制包括以下:

...
Read More

MySQL 5.6参数说明

2014-11-25

MySQL 5.6参数说明

core_file

Server崩溃的时候将相关信息写到core文件里, 系统产生core文件需调大ulimit -c 参数, 文件名默认以.pid结尾.

explicit_defaults_for_timestamp

在MySQL中,timestamp类型不同于其它标准数据类型的处理，默认情况下, timestamp列指定为允许NULL属性的话,给该列NULL值即给该列current timestamp值; 第一个为timestamp类型的列可以指定DEFAULT CURRENT_TIMESTAMP或 ON...

Read More

max_allowed_packet and binary log corruption问题说明

2014-11-19

max_allowed_packet参数指定了Server可以读取或创建的最大网络包的大小,在5.6.5版本之前默认为1MB, 5.6.6及之后的版本默认为4MB, 该参数最大可指定1GB大小, 在主从环境中关于该参数的限制有下面2点:

1. master端写binlog中的事件不能大于max_allowed_packet参数指定的大小; 2. 在所有slave 节点上的max_allowed_packet参数的值应该和master一样;

正常情况下, slave 得到 max_allowed_packet 相关的错误信息， 通常加大max_allowed_packet(上限1GB) 就可以处理该问题, 不过在异常情况下, 错误信息可能提示存在大于1G的包, 这是不可能的错误, 大部门原因是由于binlog文件中断引起,...

Read More