感知SQL运行时的状态1. 说在前面的话在MySQL里，一条SQL运行时产生多少磁盘I/O，占用多少内存，是否有创建临时表，这些指标如果都能观测到，有助于更快发现SQL瓶颈，扑灭潜在隐患。从MySQL 5.7版本开始，performance_schema就默认启用了，并且还增加了sys schema，到了8.0版本又进一步得到增强提升，在SQL运行时就能观察到很多有用的信息，实现一定程度的可观测性。下面举例说明如何进行观测，以及主要观测哪些指标。2. 安装employees测试库安装MySQL官方提供的employees测试数据库，戳此链接(https://dev.mysql.com/doc/index-other.html)下载，解压缩后开始安装：$ mysql -f < employees.sql; INFO CREATING DATABASE STRUCTURE INFO storage engine: InnoDB INFO LOADING departments INFO LOADING employees INFO LOADING dept_emp INFO LOADING dept_manager INFO LOADING titles INFO LOADING salaries data_load_time_diff 00:00:37MySQL还提供了相应的使用文 ...继续阅读 (12)

上一篇文档介绍了如何构建gdb跟踪调试环境，本文介绍如何根据错误日志信息，跟踪定位问题可能的原因，以及如何利用coredump文件查找问题线索。1. 启用coredump程序运行过程中可能会异常终止或崩溃，OS会把程序挂掉时的内存状态记录下来，写入core文件，这就叫 coredump，通过gdb结合core文件可以方便地进行调试。利用core文件中保留的异常堆栈文件，能够帮助研发同学更快定位问题。因此，如果某些故障断断续续会出现，建议阶段性开启coredump功能。想要开启coredump，需要先修改OS层的几个设置：$ ulimit -c unlimited $ sysctl -w fs.suid_dumpable=2 $ echo "core.%p.%e.%s" > /proc/sys/kernel/core_pattern同时，将这些修改持久化到相应文件中（假定MySQL/GreatSQL服务进程的属主用户是mysql）：$ echo "mysql - core unlimited" >> /etc/security/limits.conf $ echo "fs.suid_dumpable=2" >> /etc/sysctl.conf $ echo "kernel.core_pattern=core.%e.%p.%t" >> /etc/sysctl.conf $ s ...继续阅读 (6)

有时为了跟踪故障需要调试MySQL/GreatSQL源码，本文介绍如何在Linux下构建MySQL/GreatSQL源码调试环境。在这之前，我也是一名小白，一起从零开始探索吧。本文以CentOS 8.x环境下的GreatSQL 8.0.25-16版本为例。1. 编译GreatSQL查看系统环境：$ cat /etc/system-release CentOS Linux release 8.4.2105首先，从https://gitee.com/GreatSQL/GreatSQL/releases/下载GreatSQL 8.0.25-16的源码包Source CodePackagesSizegreatsql-8.0.25-16.tar.gz503M接下来，参考文章在Linux下源码编译安装GreatSQL构建好编译环境。然后开始编译GreatSQL源码，编译参数中增加/修改debug相关选项，这样编译后得到的二进制文件才能支持调试模式，例如：$ cd /opt/greatsql-8.0.25-16 $ mkdir -p build $ cd build $ cmake3 .. \ -DBOOST_INCLUDE_DIR=/opt/boost_73_0 \ -DLOCAL_BOOST_DIR=/opt/boost_73_0 \ -DCMAKE_INSTALL_PREFIX=/usr ...继续阅读 (5)

感知SQL运行时的状态1. 说在前面的话在MySQL里，一条SQL运行时产生多少磁盘I/O，占用多少内存，是否有创建临时表，这些指标如果都能观测到，有助于更快发现SQL瓶颈，扑灭潜在隐患。从MySQL 5.7版本开始，performance_schema就默认启用了，并且还增加了sys schema，到了8.0版本又进一步得到增强提升，在SQL运行时就能观察到很多有用的信息，实现一定程度的可观测性。下面举例说明如何进行观测，以及主要观测哪些指标。2. 安装employees测试库安装MySQL官方提供的employees测试数据库，戳此链接(https://dev.mysql.com/doc/index-other.html)下载，解压缩后开始安装：$ mysql -f < employees.sql; INFO CREATING DATABASE STRUCTURE INFO storage engine: InnoDB INFO LOADING departments INFO LOADING employees INFO LOADING dept_emp INFO LOADING dept_manager INFO LOADING titles INFO LOADING salaries data_load_time_diff 00:00:37MySQL还提供了相应的使用文 ...继续阅读 (9)

>GIPKs解决了历史难题1. GIPKs特性简介从MySQL 8.0.30开始，新引入一个叫做GPIKs的特性，其全称是Generated Invisible Primary Keys，简言之就是自动生成隐含的主键列，更完整的说法是：启用GIPKs后，当新建的InnoDB表没有显式主键时，会自动创建一个不可见的主键列my_row_id，这个列会被定义为bigint unsigned NOT NULL AUTO_INCREMENT，并且是不可见的（INVISIBLE）。2. GIPKs特性的作用实际上这个特性在有些分支版本上早就已经实现了，这个需求也是非常迫切，MySQL官方对这个特性的支持虽迟但到，积极意义还是很大滴，解决了几个历史难题：1. DBA无需再和开发battle，强调一定要有显式自增主键列。当然了，个别情况下非要显式指定非自增列（例如选择UUID/VARCHAR类型列）做主键的，DBA也无可奈何啊。2. 在MGR架构中，也不用要求每个InnoDB表都必须要有显式定义的主键列。上述这两种情况下，都可以从GIPKs特性中获益，会自动创建隐含的my_row_id主键列。GIPKs特性带来的一点点不便是，当我们想要显式创建一个名为my_row_id的列名时，会报错，不让创建，因为被GIPKs特性给当做保留关键字了，例如：greatsql> create table t2( i ...继续阅读 (6)

上一篇文档介绍了如何构建gdb跟踪调试环境，本文介绍如何根据错误日志信息，跟踪定位问题可能的原因，以及如何利用coredump文件查找问题线索。1. 启用coredump程序运行过程中可能会异常终止或崩溃，OS会把程序挂掉时的内存状态记录下来，写入core文件，这就叫 coredump，通过gdb结合core文件可以方便地进行调试。利用core文件中保留的异常堆栈文件，能够帮助研发同学更快定位问题。因此，如果某些故障断断续续会出现，建议阶段性开启coredump功能。想要开启coredump，需要先修改OS层的几个设置：$ ulimit -c unlimited $ sysctl -w fs.suid_dumpable=2 $ echo "core.%p.%e.%s" > /proc/sys/kernel/core_pattern同时，将这些修改持久化到相应文件中（假定MySQL/GreatSQL服务进程的属主用户是mysql）：$ echo "mysql - core unlimited" >> /etc/security/limits.conf $ echo "fs.suid_dumpable=2" >> /etc/sysctl.conf $ echo "kernel.core_pattern=core.%e.%p.%t" >> /etc/sysctl.conf $ s ...继续阅读 (5)

有时为了跟踪故障需要调试MySQL/GreatSQL源码，本文介绍如何在Linux下构建MySQL/GreatSQL源码调试环境。在这之前，我也是一名小白，一起从零开始探索吧。本文以CentOS 8.x环境下的GreatSQL 8.0.25-16版本为例。1. 编译GreatSQL查看系统环境：$ cat /etc/system-release CentOS Linux release 8.4.2105首先，从https://gitee.com/GreatSQL/GreatSQL/releases/下载GreatSQL 8.0.25-16的源码包Source CodePackagesSizegreatsql-8.0.25-16.tar.gz503M接下来，参考文章在Linux下源码编译安装GreatSQL构建好编译环境。然后开始编译GreatSQL源码，编译参数中增加/修改debug相关选项，这样编译后得到的二进制文件才能支持调试模式，例如：$ cd /opt/greatsql-8.0.25-16 $ mkdir -p build $ cd build $ cmake3 .. \ -DBOOST_INCLUDE_DIR=/opt/boost_73_0 \ -DLOCAL_BOOST_DIR=/opt/boost_73_0 \ -DCMAKE_INSTALL_PREFIX=/usr ...继续阅读 (5)

继续吹MySQL 8.0~在以前，当需要对MySQL数据库进行维护操作时，通常需要先进行主从切换，然后修改设置并重启实例，关闭网络监听，只允许从本地socket方式登入，再进行相应的维护操作；有时候甚至还要修改相应的防火墙，或者干脆关闭前端业务服务，总体比较麻烦。从MySQL 5.7开始，支持设置为离线模式（offline_mode），再有维护操作需求就不用这么麻烦了。只需在线动态修改，可立即生效，非常的简单粗暴：mysql> set global offline_mode = on; -- 打开离线模式，拒绝外部请求 mysql> set global offline_mode = off; -- 关闭离线模式，允许外部连接请求当设置为离线模式后，普通用户将无法继续发起连接请求，甚至当前正在执行的SQL也会立即被终止并被断开连接。1. 无法创建新连接$ mysql -h127.0.0.1 -uyejr -pyejr -P4306 sbtest mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 3032 (HY000): The server is currently in offline mode2. 即便是普通用户通过本地socket连接，当启用离线模式 ...继续阅读 (5)

MySQL 8.0.28引入的新功能MySQL 8.0.28开始，新增一个特性，支持监控统计并限制各个连接（会话）的内存消耗，避免大量用户连接因为执行垃圾SQL消耗过多内存，造成可能被OOM kill的风险。首先，需要先设置系统选项global_connection_memory_tracking = 1，之后可以通过系统状态变量Global_connection_memory查看当前所有连接消耗的内存总量：mysql> show global status like 'Global_connection_memory'; +--------------------------+---------+ | Variable_name | Value | +--------------------------+---------+ | Global_connection_memory | 1122912 | +--------------------------+---------+系统选项global_connection_memory_tracking可以全局开启，也可以在单个会话中独立开启。如果是全局开启，则会针对所有连接统计内存消耗情况，包括系统内部线程，以及root用户创建的连接；如果是单个会话中独立开启，则只会统计当前会话连接的内存消耗。此外，In ...继续阅读 (5)

MySQL 8.0 up up up~从MySQL 5.7开始，支持在线动态调整 innodb buffer pool，并为此新增了一个状态变量Innodb_buffer_pool_resize_status，可以通过观察它了解调整buffer pool过程中的一些状态，例如Resizing also other hash tables.或Completed resizing buffer pool at 230131 15:57:03.。从8.0.31开始，针对innodb buffer pool在线动态resize特性，新增了下面两个状态变量，可以更方便透明观察resize的进度：状态变量解释Innodb_buffer_pool_resize_status_codebuffer pool resize状态码，共有以下几种不同值：– 0: No Resize operation in progress– 1: Starting Resize– 2: Disabling AHI (Adaptive Hash Index)– 3: Withdrawing Blocks，清除/降低buffer pool pages（主要针对buffer pool缩小的情况）– 4: Acquiring Global Lock– 5 ...继续阅读 (7)

每周学点MGR知识。1. 三节点的MGR集群，有两个节点宕机后还能正常工作吗要看具体是哪种情况。如果两个节点是正常关闭的话，则会向MGR集群发送退出信号，这种情况下，这两个节点属于正常退出，最后仅剩的节点会被提升为Primary角色，还可以正常工作，允许对其进行读写，只是此时没有可用性冗余了。当其他节点再次启动并加入集群后，又能恢复正常服务。如果是因为网络故障，或者mysqld进程发生oom、或被误杀、或其他原因退出了，则这些节点会被标识为UNREACHABLE状态，等待直到group_replication_member_expel_timeout时长（单位：秒）后这个节点才会正式退出集群。在这种情况下，一旦超过多数派节点处于UNREACHABLE状态时，则整个集群不可用，无法提供读写服务。这种情况下，需要把剩下的节点重启MGR服务才能恢复。正常情况下，不要把group_replication_member_expel_timeout值调整太大，并且MGR的事务一致性级别尽量不要选择AFTER模式，以防出现整个集群服务不可用的问题，详细参见这篇文章：为什么MGR一致性模式不推荐AFTER。2. MGR可以像主从复制那样只启动两个节点吗MGR在初始化启动时，是可以只启动两个节点，甚至只有一个节点，但是这样就失去MGR的意义了。因为只要少于三个节点，就没办法进行多数派投票，当发生网络 ...继续阅读 (10)

MySQL优化器索引选择迷思。高鹏（八怪）对本文亦有贡献。1. 问题描述群友提出问题，表里有两个列c1、c2，分别为INT、VARCHAR类型，且分别创建了unique key。SQL查询的条件是WHERE c1 = ? AND c2 = ?，用EXPLAIN查看执行计划，发现优化器优先选择了VARCHAR类型的c2列索引。他表示很不理解，难道不应该选择看起来代价更小的INT类型的c1列吗？2. 问题复现创建测试表t1：[root@yejr.run]> CREATE TABLE `t1` ( `c1` int NOT NULL AUTO_INCREMENT, `c2` int unsigned NOT NULL, `c3` varchar(20) NOT NULL, `c4` varchar(20) NOT NULL, PRIMARY KEY (`c1`), UNIQUE KEY `k3` (`c3`), UNIQUE KEY `k2` (`c2`) ) ENGINE=InnoDB;利用mysql_random_data_load写入一万行数据：mysql_random_data_load -h127.0.0.1 -uX -pX yejr t1 10000查看执行计划：[root@yejr.run]> EXPLAIN SELECT * F ...继续阅读 (15)

一文快速掌握 MySQL进程号、连接ID、查询ID、InnoDB线程与系统线程的对应关系。有时候，怀疑某个MySQL内存查询导致CPU或磁盘I/O消耗特别高，但又不确定具体是哪个SQL引起的。或者当InnoDB引擎内部有semaphore wait时，想知道具体是哪个线程/查询引起的。多说一下，当有semaphore wait事件超过600秒的话，InnoDB会发出crash信号：InnoDB: ###### Diagnostic info printed to the standard error stream 2020-12-13T09:41:33.810011Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung. 2020-12-13 10:41:33 0x7f3d92a4e700 InnoDB: Assertion failure in thread 139902430013184 in file ut0ut.cc line 917 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a d ...继续阅读 (15)

『叶问』#39，都有哪些情况可能导致MGR服务无法启动1. 都有哪些情况可能导致MGR服务无法启动简单整理了下，大概有以下原因可能导致MGR服务无法启动：网络原因，例如网络本来就不通，或被防火墙拦住。防火墙通常至少有两道，操作系统默认的firewall策略，以及云主机被默认的安全策略。第一个启动的节点没先做初始引导操作（group_replication_bootstrap_group=ON）。没有正确配置group_name，所有节点的group_replication_group_name值要一致才可以。没正确配置group_replication_group_name，常见于新手。要为MGR服务专门新开一个服务端口，常用33061端口，但新手可能会照样写成3306端口。通常，我们会在各MGR节点的 hosts 文件里加上所有节点的hostname。这是为了防止本地节点使用的hostname和MGR收到的hostname不一致，这种情况下，可以在每个本地节点设置report-host，主动上报hostname即可解决。没设置正确的allowlist。有可能加入MGR各节点的IP不在默认的allowlist中，可参考这篇文章：MySQL Group Replication集群对IP地址的限制导致的一些问题与解决办法。个别节点的本地事务更多，例如误操作写入数据，也会无法加入MGR， ...继续阅读 (13)

关于GreatSQL及MGR的FAQ，持续更新中。Last Update: 2021.12.14。0. GreatSQL简介GreatSQL是由万里数据库维护的MySQL分支，开源、免费。GreatSQL基于Percona Server，在其基础上进一步提升MGR（MySQL Group Replication）的性能及可靠性。此外，GreatSQL合并了华为鲲鹏计算团队贡献的Patch，实现了InnoDB并行查询特性，以及对InnoDB事务锁的优化。GreatSQL可以作为MySQL或Percona Server的可选替代方案，用于线上生产环境。GreatSQL完全免费并兼容MySQL或Percona Server。1. GreatSQL的特色有哪些相对于MySQL官方社区版，GreatSQL有以下几个优势：InnoDB性能更好支持InnoDB并行查询，TPC-H测试中平均提升聚合分析型SQL性能15倍，最高提升40多倍。优化InnoDB事务锁，tps性能可提升约10%。MGR更可靠、稳定，性能也更好。MGR中引入地理标签特性，主要用于解决多机房数据同步的问题。MGR中优化了流控算法，运行更加平稳。解决磁盘空间爆满时导致MGR集群阻塞的问题。解决MGR多主模式下或切主时可能导致丢数据的问题。解决节点异常退出MGR集群时导致性能抖动的问题。MGR节点异常状态判断更完善。重新设计MG ...继续阅读 (12)

当集群中所有节点都宕机后，集群再次启动后，能否自动选主1、MGR集群所有节点都宕机后，集群重启，能否自动选主和启动MGR服务 这是个来自群友的问题。首先，MySQL服务利用 systemd 即可实现故障后自启动，注意下面这个配置即可：[root@GreatSQL ~]# cat /usr/lib/systemd/system/greatsql.service ... Restart=on-failure其次，mysqld进程启动后，想要实现MGR的自动选主及自启动也是可以的，利用MySQL Shell即可，例如：[root@GreatSQL ~]# mysqlsh --uri greatsql@yejr-mgr3:3306 ... -- 不管干啥，都先看 help，这是玩转Linux的必备素养，啥事不清楚都先找男人（man） -- 注意到有这样的一个方法 rebootClusterFromCompleteOutage()，看起来没跑了 MySQL yejr-mgr3:3306 ssl JS > \help dba rebootClusterFromCompleteOutage([clusterName][, options]) Brings a cluster back ONLINE when all members are OFFLI ...继续阅读 (12)

本次介绍如何利用Docker构建Ubuntu环境，并将GreatSQL源码编译成二进制文件。1、准备工作先创建本次Docker的workdir为 /data/docker-ubuntu：[root@greatsql ~]# mdkir /data/docker-ubuntu1.1、配置Ubuntu环境下的apt源配置文件开始编译之前，建议先配置好apt源，这样后续部署环境下载软件包时速度更快。以阿里、腾讯两大云主机为例，可以这样配置（两个apt源自行二选一）：#腾讯云 [root@greatsql ~]# cat /data/docker-ubuntu/ubuntu-20.4-sources.list deb http://mirrors.cloud.tencent.com/ubuntu/ focal main restricted deb http://mirrors.cloud.tencent.com/ubuntu/ focal-updates main restricted deb http://mirrors.cloud.tencent.com/ubuntu/ focal universe deb http://mirrors.cloud.tencent.com/ubuntu/ focal-updates universe deb http://mirrors.c ...继续阅读 (18)

1. 三节点的MGR集群关掉两个节点后还能继续读写吗这里要先明确一个前提，两个节点是正常关闭MGR服务，还是异常宕机。如果两个节点是手动执行stop group_replication关闭的话，那仅剩的一个节点（会成为PRIMARY节点）是可以正常读写的，只不过这是MGR集群没任何容错能力了（想想MGR集群刚启动第一个节点时的场景…）。但如果两个节点是异常宕机导致离开集群的话，那么相当于MGR里的多数派（两个节点）缺失了，只剩下少数派（一个节点），此时就无法提供读写服务了，类似下面这种情况：root@GreatSQL> select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE ...继续阅读 (16)

叨叨最近遇到的一些事以及见闻、思考。1. GreatSQL编译环境Dockerfile更新了用于构建GreatSQL编译环境的Dockerfile发现几个小瑕疵，于是更新了下。利用Docker环境来编译GreatSQL显然更方便，一次构建即可多次使用，非常推荐这种方式。有兴趣的戳此查看最新Dockerfile。另外，这是自制Docker镜像参考。欢迎留言提建议呀。2. MGR分享直播最近两周，分别尝试了在工作日白天和晚上直播分享MGR相关内容，测试下来发现放在晚上似乎人会更多些，可能白天大家还有手头的工作要处理，所以参加的人略少些。相比回看录制好的视频，大家似乎更喜欢参加直播，可能录播视频给人一种反正现在不看以后还可以再看的心态，而直播则是过了就没了，所以似乎更愿意参加。以后打算继续继在晚上做直播分享了，预计周二、四的晚上吧，我会尽量提前预告。若有更好的建议也请留言。3. 为什么 INSERT … SELECT 会报告锁等待超时错误这是因为在默认的RR（repeatable read）隔离级别下，INSERT INTO t … SELECT FROM s事务中，对要读取的源s表所涉及的数据要加上next-key lock。因此如果此时有其他事务也正对这些数据加锁的话，是有可能导致行锁没释放，报告锁等待超时。此时可以通过查看performance_schema.data_ ...继续阅读 (22)

叨叨最近遇到的一些事以及见闻、思考。1. 【重要提醒】做好数据备份这里不仅是指数据库的数据，也包括日常工作、生活中产生的数据，例如工作电脑（重要文档资料等）、手机数据（照片、通信录等）。平时可能不觉得多么重要，而一旦发生损坏或者丢失时，就会痛心疾首了。。。无数次惨痛的经验教训反复的说明数据备份的重要性。这里要特别表扬macOS系统的TimeMachine功能，可以很方便的实现整机备份。我会专门用一个移动硬盘作为TimeMachine，大约每1-2周做一次全盘备份。电脑中的重要资料、照片等，也会双重备份到另外两个移动硬盘上。可能有同学说要上NAS，是这样没错，但我当时买移动硬盘时还没这概念，就懒得折腾了。2. GreatSQL 和 Percona 之间可以相互平滑替换吗如果是相同版本号，那么是OK的。也就是目前GreatSQL 8.0.25-15 和 Percona Server 8.0.25-15之间是可以任意平滑互换的。另外，GreatSQL 8.0.25和MySQL 8.0.25（官方社区版）也是可以平滑互换的。但是，如果是不同版本的话，则不能这样做了。例如想从Percona Server 8.0.26换成GreatSQL 8.0.25的话，就会报告类似下面的错误：[ERROR] [MY-013171] [InnoDB] Cannot boot server version 8 ...继续阅读 (22)

用systemd代替mysqld_multi管理单机多实例，也很方便。有时候，我们需要在单机环境下跑多实例。在以前，一般是习惯用mysqld_multi来跑多实例。不过从CentOS 7开始引入systemd作为新的系统管理器后，用它来管理多实例也是很方便的。本文我们以RPM/YUM方式安装后的MySQL为例，介绍如何用systemd管理多实例。以RPM/YUM方式安装完后，会生成systemd服务文件/usr/lib/systemd/system/mysqld.service，可以看到其中有两行：ExecStartPre=/usr/bin/mysqld_pre_systemd ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS在编辑/usr/bin/mysqld_pre_systemd时能看到有--defaults-group-suffix选项，它就是用于构建多实例的了。接下来，只需要简单的照猫画虎就行。复制MySQL服务文件/usr/lib/systemd/system/mysqld.service到一个新文件，例如/usr/lib/systemd/system/greatsql@.service，加上一个 @ 符号，只需修改上述提到的2行内容，其他内容照旧即可：# vim /usr/lib/systemd/system/greatsql@.serv ...继续阅读 (15)

MySQL 8.0.27刚发布，我比较关注在MGR方面做了哪些改进提升。注意到有个新特性是Single Consensus Leader，大意是在single primary模式下，把single-leader标记打开，可使得MGR性能会更好些，以及在个别节点故障时能更快恢复。我简单测试了下，性能是略有提升1%左右，机器不明显，可能是因为我测试机配置太差的缘故吧。此外，8.0.27共有200多个bug fix，但和MGR相关的bug fix并不多，官方对MGR的态度还是令人摸不透啊。。。继续安利GreatSQL吧，想要体验更可靠的MGR，以及更快的InnoDB，不妨尝试下GreatSQL（https://github.com/GreatSQL/GreatSQL）吧，这是基于Percona Server的分支，可以放心替换，用的不爽了，也可以随时换回Percona Server。对待新事物，不妨更宽容些，还是应该抱着开放的心态，多年前Percona的patch刚出来时，我就大胆的用上了，也的确解决了我的数个痛点，此后就不断向其他同行安利了。YARPP List您可能对下面这些文章也感兴趣:《叶问》35期，binlog解析出来的日志为何无法恢复问题描述 问题来自一位群友，简单说就是用 mysqlbinlog 工具读取 binlog 欲进行恢复，却发现数 […]...my. ...继续阅读 (15)

my.cnf生成器最近有几处更新，有用过的同学可以关注下相关的变动，看看是否要跟随调整。戳此链接直达：https://imysql.com/my-cnf-wizard.htmlYARPP List您可能对下面这些文章也感兴趣:一周碎碎念，2021.10.17，《南渡北归》读后感一周碎碎念，2021.10.17，《南渡北归》几条小结 叨叨最近遇到的一些事以及见闻、思考。 1. 空跑状态下 […]...[MySQL FAQ]系列 — 如何将两个表名对调问题 有位同学问我，在类似pt-osc场景下，需要将两个表名对调，怎么才能确保万无一失呢？ 分析 估计其他同学 […]...如何更快随机UPDATE？导读 UPDATE + RAND()怎么可以更快？ 有时候，我们随机更新几行数据，可能会下意识的直接写成下面的 […]...Powered byYARPP. ...继续阅读 (24)

一周碎碎念，2021.10.17，《南渡北归》几条小结叨叨最近遇到的一些事以及见闻、思考。1. 空跑状态下，MySQL MGR消耗更多CPU资源在测试MySQL vs GreatSQL的MGR表现时，发现在空跑状态下，MySQL进程会消耗更多的CPU资源，有图有真相：2. mysqlrouter对性能影响蛮大的这几天也在测试mysqlrouter作为MGR的前端中间件，发现对性能影响挺大的。在简单只读模式下，加挂mysqlrouter后，性能损失约40%，响应时延增加约60%。在简单读写模式下，加挂mysqlrouter后，性能损失约30%，响应时延增加约15%。3. 《南渡北归》读书杂感摘自豆瓣简介：《南渡北归(增订版)(套装共3册)》分为《南渡》《北归》《离别》三部，是著名作家岳南所著首部全景再现20世纪中国最后一批大师命运变迁的史诗巨著。讲述的是上个世纪大批知识分子冒着抗战的炮火由中原迁往西南之地，而后再回归中原的故事。整部作品的时间跨度近一个世纪，所涉人物囊括了二十世纪人文科学领域的大部分大师级人物，如蔡元培、王国维、梁启超、梅贻琦、陈寅恪、钱锺书等。作品对这些知识分子群体命运作了细致的探查与披露，对各种因缘际会和埋藏于历史深处的人事纠葛、爱恨情仇进行了有理有据的释解，读来令人心胸豁然开朗的同时，又不胜唏嘘，扼腕浩叹。我搜了下，这本书在中央纪委国家监委网站上也有推荐，看来分 ...继续阅读 (16)

叨叨最近遇到的一些事以及见闻、思考。1. MySQL 8.0.26 MGR不太给力前阵子拿MySQL 8.0.26和GreatSQL 8.0.25再次做了个对比测试，从测试结果来看，官方社区版还是不太给力呀。即便是在MGR的事务一致性模式选择最低的EVENTUAL级别时（group_replication_consistency=EVENTUAL），官方社区版本的tps和latency抖动还是非常明显（见下面两个贴图）。更多的测评报告见文章：简单测试MySQL 8.0.26 vs GreatSQL 8.0.25的MGR稳定性表现本来还想测试启用流控（flow control）后GreatSQL和MySQL社区版的不同表现，无奈我测试机比较一般，遂放弃。YARPP List您可能对下面这些文章也感兴趣:MySQL中MGR中SECONDARY节点磁盘满，导致mysqld进程被OOM Killed在MGR测试中，人为制造磁盘满问题后，节点被oom killed 问题描述 在对MySQL 8.0.26 vs […]...《叶问》34期，延迟从库加上MASTER_DELAY，主库宕机后如何快速恢复服务当主库宕机后，延迟从库如何才能”取消”​主动延迟，以便恢复服务？ 问题描述 本问题来自 […]...技术分享 | 利用GreatSQL ...继续阅读 (16)

在MGR测试中，人为制造磁盘满问题后，节点被oom killed问题描述在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中，有一个环节是人为制造磁盘满的场景，看看MGR是否还能正常响应请求。在实测过程中，最后发现磁盘满的那个节点，持续时间足够久后，会因为内存消耗过大而最终被OS给OOM Kill。这个问题我已报告BUG（#104979），下面是该过程的详细记录。首先，直接利用dd复制空文件填满磁盘。MySQL 8.0.26 测试过程disk full报告过程及何时被oom killed来看下MySQL 8.0.26遇到disk full时日志都输出哪些内容：# 首次提示disk full的时刻是 09:44:10.052558，这时其实还能写入日志，只是不能写数据和binlog 2021-09-18T09:44:10.052558+08:00 10 [ERROR] [MY-000035] [Server] Disk is full writing './yejr-mgr3-relay-bin-group_replication_applier.000046' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. M ...继续阅读 (16)

MySQL 8.0.26下MGR表现如何？用实测数据说话。此外，MySQL 8.0.26还存在一个严重缺陷。MySQL 8.0.26发布差不多两个月了，一直还没对它进行测评，看到release notes中涉及到几个MGR相关的Bug fixed，最近抽空对其简单测试一番，下面说说结果吧。本文后半段还会爆出MySQL 8.0.26的一个严重缺陷。本次测试采用sysbench，测试模式选择楼方鑫提供的mix-load方案：require("oltp_common") local runtype = 0; function prepare_statements() -- use 1 query per event, rather than sysbench.opt.point_selects which -- defaults to 10 in other OLTP scripts sysbench.opt.point_selects=1 runtype = (10 * sysbench.tid + 10) / sysbench.opt.threads if runtype <= 6 then prepare_point_selects() else prepare_non_index_updates() end e ...继续阅读 (12)

叨叨最近遇到的一些事以及见闻、思考。1. GreatSQL/MGR课程上线啦向大家报告下GreatSQL/MGR专题课程的进度，该课程现已上线，不过还差两个视频没录完。第一期内容相信有很多不足，甚至错漏的地方，也欢迎各位不吝留言帮忙提建议、意见，帮忙改进完善，感谢。扫码或复制链接在浏览器中打开GreatSQL社区《实战MGR》2. 在MGR中，开启writeset和组提交会冲突吗这是来自一位群友的问题。这是不冲突的，采用writeset仍然可以组提交。3. MySQL有全同步模式吗？严格上讲，目前是没有全同步模式架构的。不过，在MGR里，选择 BEFORE_AND_AFTER 也勉强可以算全同步模式吧。4. MGR单主模式下，需要另外两个节点全部确认才能提交，还是只需要一个节点确认就可以提交？MGR单主模式下，虽然只有一个节点能进行写入，但其实其他节点也要参与事务认证的，所以还是需要达成多数派共识才行。预告下，GreatSQL分支计划推出一个新功能，在单主模式下，可以选择只在本地节点认证，无需多数派认证，效率会更高。不过同时要求其他节点不能手动关闭 super_read_only 模式写数据，否则可能会造成数据不一致风险。5. 执行show databases 特别慢怎么回事大概率是这个实例下的数据对象太多了，第一次执行时要加载这些数据对象，所以特别慢。可以尝试以下几个方法：用my ...继续阅读 (19)

引子某次测试过程中，发现在 AFTER 级别下，节点故障会导致集群无法进行事务提交，同时，当事务进入提交阶段后，其它节点无法开启只读事务。整个集群无法正常提供服务，直到故障节点被踢出集群。以下首先复现上述故障场景的步骤。初始化一个3节点的集群。集群信息如下：mysql> select * from performance_schema.replication_group_members;+—————————+————————————–+————-+————-+————–+————-+—————-+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | ...继续阅读 (16)

经过几个月的紧张筹备，GreatSQL宣布正式开源。GreatSQL是源于Percona Server的分支版本。GreatSQL在Percona Server已有的稳定可靠、高效、管理更方便等优势基础上，进一步提升了MGR（MySQL Group Replication）的性能及可靠性，新增金融级应用场景需求特性并修复数个影响可靠性的严重bug。GreatSQL可以作为MySQL或Percona Server的可选替代方案，用于线上生产环境。GreatSQL完全免费并兼容MySQL或Percona Server。GreatSQL由万里数据库发起、主导、维护，也欢迎广大MySQL使用者、爱好者下载使用，或者提交代码、issue等。1. 使用MySQL社区版存在什么风险万里数据库核心研发团队深入研究MGR架构，并在不断的BUG修复实践中总结出了一套完善、流畅的BUG修复流程，将MGR的缺陷分为BUG和性能两类，整理出共16种BUG及性能缺陷问题。搜索MySQL官方bug站，可以看到MGR分类下未修复的bug数量还是比较多的：当服务器配置高，网络环境好，业务量小的时候，这些MGR相关的bug可能不容易碰到。如果是网络环境稍微复杂一些，例如同城多数据中心环境，甚至跨交换机，都可能会遇到网络分区条件下的一些bug。或者当业务量较大，负载较高时，可能会产生丢数据、OOM，或事务频繁回 ...继续阅读 (18)