ITPub博客

本文将为大家呈现RR与RC隔离级别下MySQL不同的加锁解锁方式~

本文尝试从使用本地存储的场景出发，分享了“VolumeScheduling”在代码中的具体实现和场景局限。

Docker让软件开发过程中的环境构建变得简单，消除软件测试过程中环境不一致导致的问题，又让运维和部署变得轻松快速。

随着交流机会的增多(集中在金融行业, 规模都在各自领域数一数二), 发现大家对 Docker + Kubernetes 的接受程度超乎想象, 并极有兴趣将这套架构应用到 RDS 领域. 数据库服务的需求可以简化为:

不管是架构选型还是生活，绝大多数时候都是在做 trade off，收获了计算存储分离带来的好处，也意味着要忍受它带来的一些棘手问题。本文尝试结合 Kubernetes, Docker, MySQL和计算存储分离架构, 分享我们遇到的“Split-Brain”问题。

沃趣 QFusion 采用目前已经非常成熟且应用非常广泛的主从复制数据同步架构，在能保证高性能的前提下，结合商业的高性能、高可用的分布式存储QCFS实现了数据零丢失，同时我们从BIOS、硬件配置、文件系统、操作系统内核、MySQL配置参数等自底向上做了大量的整体优化，使得单位时间内的交易量进一步提升。根据我们全方位的测试与对比，相比开源的数据同步解决方案，沃趣 QFusion 极具性能与稳定性优势。

在基于 Kubernetes 和 Docker 构建的私有 RDS 中, 普遍采用了计算存储分离架构. 该架构优势明显, 但对于数据库类 Latency Sensitive 应用而言, IO 性能问题无法回避, 下面分享一下我们针对 MySQL 做的优化以及优化后的收益.

在基于 Kubernetes 和 Docker 构建的私有 RDS 中，普遍采用了计算存储分离架构。该架构优势明显， 但对于数据库类 Latency Sensitive 应用而言，IO 性能问题无法回避，下面分享一下我们针对 MySQL 做的优化以及优化后的收益。

我们平时测试MySQL时，大多数时候都是使用的sysbench、tpcc-mysql等基准测试工具，现在，你可以尝试着使用hammerdb来对MySQL做一做基准测试，虽然hammerdb测试工具大多数时候我们听到的都是用于oracle测试。但却不失为一种选择。另外，前面提到过，hammerdb还支持olap场景的基准测试，大家有兴趣的可以试一试。

从上文中冗长的分析过程，我们可以得知，导致出问题的起因是主库持续写入的情况下，从库执行stop slave;时，IO线程读取并只向relay log中写入了一个事务的部分event（event组不完整，只写了GTID EVENT），后续change master to master_auto_position=0语句既没有指定请求主库的binlog位置，也没有指定从库的relay log，导致mysql server执行了清理relay log（清理了IO线程最后写入的GTID EVENT）以及 relay log和SQL线程相关的表和内存中的位置信息，并把SQL线程的位置指向了IO线程的停止位置（IO线程读取的主库binlog file and pos），后续start slave;时从库就从IO线程停止的位置开始复制，由于IO线程停止时的位置处在一个事务的中间，SQL线程从这个位置开始应用时，立即发现了这个事务缺少GTID event，被误认为是一个 匿名事务（gtid_mode系统参数设置为ON时，IO线程和SQL线程都不允许碰到匿名事务），所以SQL协调器线程和worker线程

今天咱们同事说碰到一个古怪的问题，说MySQL 5.7.18上，主从复制结构中，从库在使用change master语句切换master_auto_position=1为0时，SQL线程报错了([ERROR] Slave SQL for channel '': Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: 'sbtest'. Query: 'BEGIN', Error_code: 1782)，然后，出于尝试修复，又改成了1，重新启动复制就恢复正常了，然后再改成0重新启动复制，这个时候发生数据丢失了，再反复切换几次之后，MySQL crash了。。，当时我听到这个问题的第一反应就是：一脸懵逼（因为1782错误通常是发生复制架构启用GTID复制之后，从库IO线程读取到主库的ANONYMOUS 事务时报错）。。然后，发了一阵呆之后，想到了一些可能导致这个问题的原因，下文我们通过"复现与简单分析"、"重新复现、详细分

上周同事在客户现场遇到了由于统计信息的原因，导致应用数据迁移时间过慢，整个迁移差点失败。关键时刻同事发现测试环境与生产环境SQL语句执行计划不一致，立刻收集统计信息才保证迁移得以正常完成。 统计信息对于SQL的执行时间有重要的影响，统计信息的不准确会导致SQL的执行计划不准确，从而致使SQL执行时间变慢，Oracle DBA非常了解统计信息的收集规则，同样在MySQL中也有相关的参数去控制统计信息。

作为专职的DBA：我们一定一定要保持一种高度谨慎的态度，在数据库备份方案选型时，一定要根据自己的业务场景充分测试，校验，尽可能地把可能出现的深坑挖出来。除了寻找适合自己的，可行的备份方案之外，更应该做好备份校验（备份是否成功完成、备份文件是否损坏）、备份恢复演练（备份文件是否可以正常恢复数据），以备不时之需。对生产库的DDL操作、大事务、或者长时间锁表的操作，一定要避开备份时间，否则，你懂的……

想必大家都知道，mysqldump备份时可以使用--single-transaction + --master-data两个选项执行备份（老实讲，为图方便，本人之前很长一段时间，生产库也是使用mysqldudmp远程备份的），这样备份过程中既可以尽量不锁表，也可以获取到binlog pos位置，备份文件可以用于数据恢复，也可以用于搭建备库。看起来那么美好，然而，其实一不小心你就发现自己已经在坑里了。

沃趣科技  罗小波1.2.3. 使用WITH CONSISTENT SNAPSHOT子句的作用START TRANSACTION语句使用WITH CONSISTENT SNAPSHOT子句时，会为事务启动一致性读(该子句仅适用于InnoDB)。其行为与执行START TRANSACTION语句之后+一个SELECT语句效果相同（会获取一个事务号，在read view中占个坑，但是...

要查看备份过程中这俩备份工具都对数据库做了什么操作，想必大家都知道：可以打开general_log来查。那么问题来了，general_log输出的信息都代表什么？如果不这样做会怎样？这两个备份工具会不会有什么平时被忽略的坑？请看下文分析，也许……你会发现原来之前对这俩备份工具好像也不是那么了解!

此次简单介绍了Performance Schema的使用，后面会逐步介绍使用Performance Schema的一些实战功能。

想必数据库的同行们都知道，热点数据导出导入的动作，使得数据库重启之后，不需要再耗费大量的时间来预热，使得因为热点数据的原因导致数据库性能波动的时间大大减少，那么执行热点数据的导出与导入操作时究竟对数据库的性能有没有影响呢？如果你的服务器拥有超大内存，而且设置了一个对应内存一定比例的超大buffer pool，是否在纠结需不需要设置热点数据在重启时自动导出导入呢？下面一起看演示过程，答案就在其中。

玩过binlog server的同学都知道，它使用mysqlbinlog命令以daemon进程的方式模拟一个slave的IO线程与主库连接，可以很方便地即时同步主库的binlog，以便弥补定时备份策略中最近一次备份到下一次备份完成之前这段时间内的数据容易丢失的问题。

如果你要写一个脚本调用mysql命令来获得server_id的值，这个Warning的信息绝对是你的噩梦。 提示这个安全原因本来无可厚非，但是坑爹的是，没有任何一个参数或者开关能关闭这个Warning。