一周碎碎念,2021.11.7,两个MGR集群间还可以构建传统的主从复制通道吗

叨叨最近遇到的一些事以及见闻、思考。

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_lock_waits 来确认行锁等待情况。

4. MGR集群从节点可以2个以上吗

这是来自一位群友的问题,看来还是有不少群友对MGR没什么概念。虽然是基础问题,也值得回答一下。

目前在整个MGR集群中最多可支持9个节点。采用 single-primary 模式(group_replication_single_primary_mode = ON)时,则最多可以有8个SECONDARY节点。而如果采用 multi-primary 模式(group_replication_single_primary_mode = OFF)的话,则都是 PRIMARY 节点,不再有 SECONDARY 节点了。

5. 两个MGR集群间还可以构建传统的主从复制通道吗

答案是肯定的,可以。

在MGR集群里,只有PRIMARY节点才能作为传统主从复制的SLAVE节点,集群里的 SECONDARY 节点是不能成为传统主从复制的 SLAVE节点的(想想也能理解,否则就会造成MGR里主从节点数据不一致了)。

群友补充提问:MGR1的secondary -> MGR2的primary行不行?只能主到主?还是主到主,从到主都行?这里说的只是从节点必须是主节点吧?主节点有要求吗?

下图是在MGR里构建传统主从复制通道的详细要求:

群友再次补充提问:可以通过rooter去连接主节点吗,或者当发生了主节点切换怎么办?

首先,一个mysqlrouter实例只能连接一个MGR集群,是不能连接到多个MGR集群的。

其次,两个MGR集群间构建主从复制通道后,如果担心主节点切换时复制通道会断掉的话,可以利用MySQL 8.0.22后新增的 Async Replication Auto failover 特性,指定多个复制通道的 MASTER源,利用该特性可以应对主节点 切换的场景,详情见这两篇文章:

最后,这些内容在《实战MGR》 免费课程里已有详细介绍,欢迎加入学习。

6. 睡前看会书

最近利用晚上睡前的时间,陆陆续续把刘慈欣的几个科幻短片给看完了,印象深刻的主要有《朝闻道》、《山》、《带上她的眼睛》、《中国太阳》等几篇。刘慈欣的脑洞真的是很大,如果能把这些都拍成电影的话,想必也会挺卖座的。

发现睡前看会书这种方式还不错,晚上睡眠质量似乎也会更好些,可能是看书让人更容易静下来吧,之前的《南渡北归》也是这样陆续看完的,睡眠不好的同学可以试试这个方法。

一周碎碎念,2021.10.31,重启跑步

叨叨最近遇到的一些事以及见闻、思考。

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 80025 on data directory built by version 80026. Downgrade is not supported

也就是不能直接降级,需要通过物理或逻辑备份&导入的方式重建。

3. 哪种方式加载数据最快?

这其实是一位群友的问题,我利用空闲时间简单做了下测试,大概得到以下几点总结:

  • 同等条件下,load data infile最快,比导入用mysqldump出来的SQL文件快76%。
  • 想要导入更快,可以在导入期间关闭binlog,如果是在主从或MGR架构里,则在每个节点都要重复执行相同的导入操作,这样才能保证个节点间数据一致,关闭binlog至少能节省34%的时间。
  • 另外,还可以临时关闭redo log(MySQL 8.0.21后支持),大概能节省15%的时间。
  • 非常重要的一点,用mysqldump导出逻辑备份SQL文件时,务必要设置参数 –extended-insert=true (也是默认行为),其他类似工具也是如此。启用这个参数后,导出SQL文件会将多行数据合并到同一个INSERT里,否则的话,未开启binlog时至少慢5倍,开启binlog时至少慢20倍。

再补充两点:

  • 在已经采用批量导入(load data infile 或 –extended-insert=true)前提下,是否设置双1的耗时区别很小。
  • 同上前提,是否关闭double write buffer的区别也不大。

以上耗时数据均是基于有400万行数据的sysbench表测试而来,实际环境中肯定是不一样的,不过应该不会有特别大出入,有兴趣的同学可自行测试一波。

4. 重启跑步

昨天参加完(COSCon’21福州站在线)[https://segmentfault.com/area/coscon-2021]分享后,出门去跑了5公里。这是国庆节前手术后的第一次跑步,感觉恢复差不多了,跑下来总体感觉也还可以,配速和心率略微不太稳定外,步频倒还比较稳定。

平时有小毛病还是要及早重视起来,尽早处理哈。

利用systemd管理MySQL单机多实例

用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@.service
...
ExecStartPre=/usr/local/GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64/bin/mysqld_pre_systemd %I
ExecStart=/usr/local/GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64/bin/mysqld --defaults-group-suffix=@%I $MYSQLD_OPTS
...

在这里我改成GreatSQL的二进制路径,如果缺少 mysqld_pre_systemd 文件,可以从 /usr/bin/mysqld_pre_systemd 复制一份,然后做些微调即可,详细可参考 技术分享 | 将GreatSQL添加到系统systemd服务。

接下来编辑修改 /etc/my.cnf 配置文件,在原来的基础上增加多实例相关的几个片段即可,例如:

[mysqld@mgr01]
datadir=/data/GreatSQL/mgr01
socket=/data/GreatSQL/mgr01/mysql.sock
port=3306
server_id=103306
log-error=/data/GreatSQL/mgr01/error.log
group_replication_local_address= "127.0.0.1:33061"

[mysqld@mgr02]
datadir=/data/GreatSQL/mgr02
socket=/data/GreatSQL/mgr02/mysql.sock
port=3307
server_id=103307
log-error=/data/GreatSQL/mgr02/error.log
group_replication_local_address= "127.0.0.1:33071"

#更多实例照此方法继续复制即可

然后执行命令 systemctl daemon-reload 重新加载systemd服务,即可识别到这些新增加的服务列表了:

$ systemctl -l

... greatsql@mgr01.service loaded active running GreatSQL Server... greatsql@mgr02.service loaded active running GreatSQL Server... greatsql@mgr03.service loaded active running GreatSQL Server... ... 

现在可以直接执行类似下面的命令启停多实例服务:

$ systemctl start greatsql@mgr01

这就可以在单机环境下很方便的管理多实例服务了。

Enjoy GreatSQL。

MySQL 8.0.27发布了

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刚出来时,我就大胆的用上了,也的确解决了我的数个痛点,此后就不断向其他同行安利了。

my.cnf生成器有几处更新

my.cnf生成器最近有几处更新,有用过的同学可以关注下相关的变动,看看是否要跟随调整。戳此链接直达: https://imysql.com/my-cnf-wizard.html