mysql

Mysql复制无法重命名schema名，导致拆库后两边一样的名称对维护和理解是比较困扰的。 间接的重命名方法有以下两种思路：1)备库使用federated存储引擎，指向重命名的库. 2)在复制的同时使用触发器，触发写入重命名的库. 接下来就就对两种方法进行性能测试: 备库为空表,从生产数据库进行复制某一写并发最高的表,备库的SQL线程压力打满。 1)默认复制: 17003 QPS 2)

最早测试过osc的功能，dtcc上也有大佬肯定过其安全性和可靠性，但未深究。最近大表的DDL变更越来越多，并且域名切换实现主从切换的方式容易出现问题，在这种驱动力下开始对osc的测试演练。测试配置 测试环境：DELL 720R RAID10 40核 128G内存 压测工具：sysbench 测试因子：thread(sysbench);chunk_size(osc) osc语句：pt-online-s

#! /bin/bash ##此基准测试脚本测试使用工具为:fio以及sysbench ##1.fio用于测试HDD和SSD ##2.sysbench用于测试mem和cpu ##3.脚本不区分挂载盘、raid策略和规格,只识别HDD还是SSD ##4.需要hikvision yum源 ##5.请使用root执行 ##6.各型号存在性能差异，脚本只做测试，不做比较 cur_t

几个参数（参考http://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html） sync_master_info：每间隔多少事务刷新master.info，如果是table（innodb）设置无效，每个事务都会更新sync_relay_log_info：每间隔多少事务刷新relay-log.info，如果是tab

序言MySQL5.7引入了基于逻辑时钟的并行复制的概念，让保守延迟困扰的我看到了一丝曙光。开心的将典型的库（6500/s TPS）升级到5.7之后，发现在默认的参数下提升并不明显。受Percona的关于并行复制这篇文章的启发，开始对参数binlog_group_commit_sync_delay调整对实际环境影响的验证。