Perl one line command – 介绍

Perl one line command - 介绍 Perl 命令行程序既轻巧又便捷, 它特指单行代码的 Perl 程序, 处理一些事情会特别方便, 比如: 更改文本行的空白符, 行数统计, 转换文本, 删除和打印指定行以及日志分析等. 熟悉命令行操作后可以节省我们大量的时间成本, 当然了解 Perl 的基本语法和一些特殊符是学习 perl 命令行的基础. Perl 在...

redis 复制功能说明

redis 复制功能说明 一. 概述 redis的复制功能可以分为同步和命令这两阶段操作, 同步操作使得 slave 的状态更新到 master 当前所在的状态, 命令传播阶段则实现增量的状态更新， 使得 master 和 slave 达到一致的状态. 在复制功能的实现中, 同步即对应着初始复制阶段, 命令传播对应着增量复制阶段. 在 client 向 slave 发送 slaveof...

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

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) 方式为例说明: server1 mkdir...

MySQL numa交叉模式启动说明

numa交叉模式说明: http://www.percona.com/doc/percona-server/5.5/performance/innodb_numa_support.html db01: 开启numa interleave; RAM 64G; db02: 关闭numa interleave; RAM 64G; 两台db均分配48G内存buffer pool; Percona Server 5.5.33版本; mysqld_safe部分配置增加numa参数: #NUMA support numa_interleave = 1 innodb_buffer_pool_populate =...

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

https://github.com/yoshinorim/MySlowTranCapture 获取执行时间超过 milliseconds事务语句的工具; 很多时候我们需要追踪事务的执行情况以判定应用程序的操作行为, 比如启了事务, 却忘记提交而造成InnoDB事务的History List不断增大. 这是很复杂的场景, 因为很难找到一个有效的方式来识别是那种sql引起的这种问题, 追踪一个长时间运行的事务不像记录一条慢查询语句, 比如执行以下事务语句: ysql root@[localhost:s3306 test] > begin; Query OK, 0 rows affected (0.00 sec) mysql root@[localhost:s3306...

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)实现了并行执行....

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的限制包括以下: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-restrictions.html 1.不要混用存储引擎 2.不要使用...

MySQL 5.6参数说明

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 UPDATE CURRENT_TIMESTAMP 属性进行自动更新; 不是第一个的timestamp类型列, 如果没有指定NULL货DEFAULT属性，则DEFAULT ‘0000-00-00 00:00:00’赋于其值。 explicit_defaults_for_timestamp选项改变这种不标准的处理行为, timestamp列没有指定NOT NULL或允许NULL,...

max_allowed_packet and binary log corruption问题说明

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文件中断引起, 举例如下: 出错信息: Got fatal error...

应用程序更新Illegal mix of collations错误说明

完整错误信息如: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (gbk_chinese_ci,IMPLICIT) for operation '=' (1267) INSERT INTO .... name = value ... 错误信息描述了操作符 = 两边的数据编码不一致而引起的冲突, 常见的原因有表的字符集可能为latin1, 而应用程序等的字符集为gbk, 当然基于这样的原因，应用程序等select出来的结果集也可能为乱码状态....