《叶问》38期,MGR整个集群挂掉后,如何才能自动选主,不用手动干预

当集群中所有节点都宕机后,集群再次启动后,能否自动选主

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 OFFLINE.

-- 跑一个试试看
MySQL  yejr-mgr3:3306 ssl  JS > dba.rebootClusterFromCompleteOutage()
Restoring the default cluster from complete outage...

The instance 'yejr-mgr4:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y

The instance 'yejr-mgr2:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y

Dba.rebootClusterFromCompleteOutage: The active session instance (yejr-mgr3:3306) isn't the most updated in comparison with the ONLINE instances of the Cluster's metadata. Please use the most up to date instance: 'yejr-mgr4:3306'. (RuntimeError)

可以看到错误信息提示我们当前节点上没有最新的数据,不能直接启动MGR,错误信息中还提供了该去哪个节点启动的建议,所以我们改成在 yejr-mgr4 节点上执行拉起MGR:

[root@GreatSQL ~]# mysqlsh --uri greatsql@yejr-mgr3:3306
...
MySQL  yejr-mgr4:3306 ssl  JS > dba.rebootClusterFromCompleteOutage()
Restoring the default cluster from complete outage...

The instance 'yejr-mgr3:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y

The instance 'yejr-mgr2:3306' was part of the cluster configuration.
Would you like to rejoin it to the cluster? [y/N]: y

yejr-mgr4:3306 was restored.
Rejoining 'yejr-mgr3:3306' to the cluster.
Rejoining instance 'yejr-mgr3:3306' to cluster 'GreatSQLMGR'...
The instance 'yejr-mgr3:3306' was successfully rejoined to the cluster.

Rejoining 'yejr-mgr2:3306' to the cluster.
Rejoining instance 'yejr-mgr2:3306' to cluster 'GreatSQLMGR'...
The instance 'yejr-mgr2:3306' was successfully rejoined to the cluster.

The cluster was successfully rebooted.

可以看到,MGR集群已经被正常启动了。

上面是利用MySQL Shell启动一个发生过故障的MGR集群,如果是手动的话该怎么办呢?

首先,在各个节点执行下面的SQL,确认各节点当前的事务执行情况:

-- yejr-mgr2节点
root@GreatSQL [none]> select RECEIVED_TRANSACTION_SET from performance_schema.replication_connection_status where 
channel_name = 'group_replication_applier' union all 
select variable_value from performance_schema.global_variables where 
variable_name = 'gtid_executed'\G
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET:
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 1c293e90-3bdc-11ec-bca1-525400e2078a:1-4537605,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1

-- yejr-mgr3节点
...
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET:
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 1c293e90-3bdc-11ec-bca1-525400e2078a:1-4542304,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1

-- yejr-mgr4节点
...
*************************** 1. row ***************************
RECEIVED_TRANSACTION_SET:
*************************** 2. row ***************************
RECEIVED_TRANSACTION_SET: 1c293e90-3bdc-11ec-bca1-525400e2078a:1-4652391,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1

从上面的结果可以看到,yejr-mgr4 节点上已执行完的事务GTID值最大:4652391 > 4542304 > 4537605,因此应该选择 yejr-mgr4 节点作为 Primary 节点。

将该节点设置为引导模式,然后启动MGR服务:

[root@GreatSQL ~]# mysql -hyejr-mgr4 -P3306 -ugreatsql -p
...
greatsql@mgr4:3306 [(none)]>set global group_replication_bootstrap_group=ON;

greatsql@mgr4:3306 [(none)]>start group_replication;

-- 启动完MGR后,记得立即将其设置为OFF
greatsql@mgr4:3306 [(none)]>set global group_replication_bootstrap_group=OFF;

在其他节点上,则直接启动MGR服务即可,切记无需再次设置引导模式,否则它就会变成一个全新的MGR集群的Primary节点了。

好了,自动、手动两种方式拉起一个故障MGR集群方法都介绍完毕了。

2、MySQL Router可以在同一个系统环境下跑多实例吗 答案是确定的,可以。

MySQL Router的手册中其实也已经有提到了:

--directory dir_path, -d dir_path

Specifies that a self-contained MySQL Router installation will be created at the defined directory instead of configuring the system-wide router instance. This also allows multiple router instances to be created on the same system.

也就是说,如果想要让MySQL Router以多实例方式运行,可以通过指定 –directory 选项将其安装在各自不同目录下。

例如下面这样:

-- 针对4306端口的服务,初始化一个router实例
-- 可自行指定目录、实例名、端口号等多个选项
mysqlrouter --bootstrap mymgr@172.16.16.16:4306 --name=MyMGR --directory=/etc/mysqlrouter/MyMGR  --user=mysqlrouter --conf-base-port=7446 --https-port=9443

初始化完成后,在每个实例相应的目录下,会有下列的文件:

$path/start.sh
$path/stop.sh
$path/mysqlrouter.pid
$path/mysqlrouter.conf
$path/mysqlrouter.key
$path/run
$path/run/keyring
$path/data
$path/log
$path/log/mysqlrouter.log

可以看到还有 start.sh / stop.sh 这样的脚本,感觉有点土味啊,哈哈。

接下来,我们要自行编辑systemd服务文件,把多个router实例管理起来,每个router实例对应一个文件:

[root@yejr-mgr4 ~]# ls -l /usr/lib/systemd/system/mysqlrouter@*
-rw-r--r-- 1 root root 312 Nov 11 14:13 /usr/lib/systemd/system/mysqlrouter@GrMGR.service
-rw-r--r-- 1 root root 312 Nov 11 14:12 /usr/lib/systemd/system/mysqlrouter@MyMGR.service

-- 查看其中一个文件的内容
[root@yejr-mgr2 ~]# cat /usr/lib/systemd/system/mysqlrouter@GrMGR.service
[Unit]
Description=MySQL Router
After=network.target
After=syslog.target
[Service]
Type=notify
User=mysqlrouter
Group=mysqlrouter
ExecStart=/usr/bin/mysqlrouter -c /etc/mysqlrouter/GrMGR/mysqlrouter.conf
LimitNOFILE = 10000
#Restart=on-failure
Restart=always
PrivateTmp=true
[Install]
WantedBy=multi-user.target

在 ExecStart 这里自行指定每个实例对应的配置文件即可。

这样就可以实现MySQL Router的单机多实例了。

3、MySQL客户端pager怎么只显示”TRANSACTIONS”和”FILE I/O”中间的内容? 用下面这个就行了:

pager cat - | sed -n "/^TRANSACTIONS$/,/^FILE I\/O$/p"
是不是很简单?

此外,可以再看下这两篇文章:

MySQL使用tips, https://imysql.com/node/69

秀下我的mysql客户端配置, https://imysql.com/2008_07_09_show_mysql_client_settings

从dump文件中抽取部分库表, https://imysql.com/2010/06/01/mysql-faq-how-to-extract-data-from-dumpfile.html

Enjoy GreatSQL :)

在Ubuntu下编译安装GreatSQL

本次介绍如何利用Docker构建Ubuntu环境,并将GreatSQL源码编译成二进制文件。

1、准备工作

先创建本次Docker的workdir为 /data/docker-ubuntu:

[root@greatsql ~]# mdkir /data/docker-ubuntu

1.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.cloud.tencent.com/ubuntu/ focal multiverse
deb http://mirrors.cloud.tencent.com/ubuntu/ focal-updates multiverse
deb http://mirrors.cloud.tencent.com/ubuntu/ focal-backports main restricted universe multiverse
deb http://mirrors.cloud.tencent.com/ubuntu/ focal-security main restricted
deb http://mirrors.cloud.tencent.com/ubuntu/ focal-security universe
deb http://mirrors.cloud.tencent.com/ubuntu/ focal-security multiverse

如果是阿里云的话换成下面的内容

deb http://mirrors.aliyun.com/ubuntu/ focal main restricted
deb http://mirrors.aliyun.com/ubuntu/ focal-updates main restricted
deb http://mirrors.aliyun.com/ubuntu/ focal universe
deb http://mirrors.aliyun.com/ubuntu/ focal-updates universe
deb http://mirrors.aliyun.com/ubuntu/ focal multiverse
deb http://mirrors.aliyun.com/ubuntu/ focal-updates multiverse
deb http://mirrors.aliyun.com/ubuntu/ focal-backports main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ focal-security main restricted
deb http://mirrors.aliyun.com/ubuntu/ focal-security universe
deb http://mirrors.aliyun.com/ubuntu/ focal-security multiverse

这个文件先准备好,后面会在Dockerfile里用到它。

另外,从我自己测试的情况,在构建docker镜像的过程中,阿里云的源更容易出错,请自行测试选定。

安装Docker,下载boost、GreatSQL源码包等这些工作我直接略过了,可直接参考这篇文档:在Linux下源码编译安装GreatSQL

我还准备了一份自动化编译GreatSQL的shell脚本,可以自取服用:

[root@greatsql ~]# cat /data/docker-ubuntu/greatsql-automake.sh

#!/bin/bash
MAJOR_VERSION=8
MINOR_VERSION=0
PATCH_VERSION=25
RELEASE=15
REVISION=`date +%Y%m%d%H%M`
BASE_DIR=/usr/local/GreatSQL-8.0.25
JOBS=16
#reversion=`echo $RANDOM | sha256sum | cut -c1-11` && echo $reversion;
cmake . -DBOOST_INCLUDE_DIR=../boost_1_73_0 -DCMAKE_INSTALL_PREFIX=${BASE_DIR} -DWITH_ZLIB=bundled \
-DWITH_NUMA=ON -DFORCE_INSOURCE_BUILD=1 -DCMAKE_EXE_LINKER_FLAGS="-ljemalloc" \
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release \
-DCOMPILATION_COMMENT="GreatSQL (GPL), Release ${RELEASE}, Revision ${REVISION}" \
-DWITH_TOKUDB=OFF -DWITH_ROCKSDB=OFF -DWITH_COREDUMPER=OFF \
-DMAJOR_VERSION=${MAJOR_VERSION} -DMINOR_VERSION=${MINOR_VERSION} -DPATCH_VERSION=${PATCH_VERSION} && \
make -j${JOBS} VERBOSE=1 && make install

1.2、构建docker镜像

用下面这份Dockerfile构建Ubuntu镜像:

FROM ubuntu
ENV LANG en_US.utf8
ARG UID=1001
ARG GID=1001
ARG UNAME=mysql
\#ENV TZ Asia/Shanghai

ENV PATH="/usr/local/mysql/bin:${PATH}"
ENV LD_LIBRARY_PATH="/usr/loca/mysql/lib:${LD_LIBRARY_PATH}"
ENV TERM=xterm

COPY ubuntu-20.4-sources.list /etc/apt/sources.list

#RUN apt-get update && apt-get install -y --no-install-recommends tzdata && rm -rf /var/lib/apt/lists/*
RUN apt update && apt install -y --no-install-recommends tzdata && rm -rf /var/lib/apt/lists/*
ENV TZ Asia/Shanghai

RUN apt update -y && apt upgrade -y && \
apt install -y --fix-missing gcc-10 cmake automake build-essential diffutils git lbzip2 libaio-dev libbison-dev \
libcurl4-openssl-dev libevent-dev libexpat1-dev libffi-dev libgflags-dev libgtest-dev libjemalloc-dev \
libldap2-dev liblz4-dev libncurses-dev libnuma-dev libreadline-dev libsnappy-dev libssh-dev libtirpc-dev \
libtool libxml2-dev libzstd-dev make net-tools numactl pkg-config psmisc vim wget \
&& groupadd -g $GID -o $UNAME && useradd -m -g $GID -u $UID -o -s /bin/bash $UNAME \
&& /usr/bin/install -m 0775 -o mysql -g root -d /var/lib/mysql /var/run/mysqld /docker-entrypoint-initdb.d \
&& /usr/bin/install -m 0664 -o mysql -g root /dev/null /etc/sysconfig/mysql

COPY patchelf-0.12.tar.gz /tmp/
RUN cd /tmp && tar -xzvf patchelf-0.12.tar.gz && cd patchelf-0.12 && ./bootstrap.sh && ./configure && make && make install

COPY rpcsvc-proto-1.4.tar.gz /tmp/rpcsvc-proto-1.4.tar.gz
RUN tar zxvf /tmp/rpcsvc-proto-1.4.tar.gz -C /tmp && cd /tmp/rpcsvc-proto-1.4/ && ./configure && make && make install

COPY boost_1_73_0.tar.gz /opt/
COPY greatsql-automake.sh /opt/

RUN rm -fr /tmp/*

开始构建docker镜像,成功后再保存到本地并导入本地镜像:

[root@greatsql ~]# docker build -t docker-ubuntu .
... ...
[root@greatsql ~]# docker save -o docker-ubuntu.tar docker-ubuntu
[root@greatsql ~]# docker load -i docker-ubuntu.tar

创建一个docker容器,并将GreatSQL源码包copy进去:

[root@greatsql ~]# docker run -itd --name greatsql --hostname=greatsql docker-ubuntu
[root@greatsql ~]# docker cp /opt/greatsql-8.0.25-15.tar.gz greatsql:/opt/
[root@greatsql ~]# docker exec -it greatsql bash
[root@greatsql /]# ls -l /opt/
-rw------- 1 root root 128699082 Jul 27 06:56 boost_1_73_0.tar.gz
-rw------- 1 1000 1000 526639994 Jul 27 05:59 greatsql-8.0.25-15.tar.gz
-rw-r--r-- 1 root root        751 Nov 12 15:25 greatsql-automake.sh

其他不同OS及架构平台下的Dockerfile可戳下面链接参考: – Dockerfile-centos7-x86Dockerfile-centos8-x86Dockerfile-centos7-armDockerfile-centos8-arm

此外,我把Docker镜像文件包也放到网盘上共享了,有兴趣的也可直接下载: – 【百度云盘】链接: https://pan.baidu.com/s/188iZ_vT4iEV7kMopgcYEFg 提取码: 8c22

2、编译GreatSQL

进入容器后,解压GreatSQL和boost源码包:

[root@greatsql /]# tar zxf /opt/greatsql-8.0.25-15.tar.gz -C /opt
[root@greatsql /]# tar zxf /opt/boost_1_73_0.tar.gz -C /opt/

可直接调用自动化编译脚本开始编译,也可以自行手动编译:

[root@greatsql /]# cd /opt/greatsql-8.0.25
[root@greatsql /]# /bin/bash /opt/greatsql-automake.sh
...

编译完成后,就会将二进制文件安装到 /usr/local/GreatSQL-8.0.25 目录下,执行下面的命令检查测试:

[root@greatsql /]# /usr/local/GreatSQL-8.0.25/bin/mysqld --verbose --version
/usr/local/GreatSQL-8.0.25/bin/mysqld  Ver 8.0.25-15 for Linux on x86_64 (GreatSQL (GPL), Release 15, Revision 202111121536)

这就编译完成了。

延伸阅读

全文完。

Enjoy GreatSQL :)

《叶问》37期,三节点的MGR集群关掉两个节点后还能继续读写吗

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 | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 99999999-9999-9999-9999-99999999999a | yejr-mgr4   |        3306 | ONLINE       | PRIMARY     | 8.0.25         |
| group_replication_applier | 99999999-9999-9999-9999-99999999999b | yejr-mgr3   |        3306 | UNREACHABLE  | SECONDARY   | 8.0.25         |
| group_replication_applier | 99999999-9999-9999-9999-99999999999c | yejr-mgr2   |        3306 | UNREACHABLE  | SECONDARY   | 8.0.25         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

这时候就要通过设置 group_replication_force_members 选项,去掉异常的两个节点,然后再将这两个节点的MGR服务重启,没其他异常的话即可自行重新加入集群。这部分内容可以回顾这个视频:MGR集群管理及节点异常处理,节点异常退出后重新加入。

P.S,如果前端挂着MySQL Router,则三节点的MGR集群中意外宕机两个节点后,这时会发出报错:

"statusText": "Cluster has no quorum as visible from 'yejr-mgr4:3306' and cannot process write transactions. 2 members are not active.",

然后MySQL Router完全不可提供服务,无论是读写端口还是只读端口,都不行。

2. 三节点同时挂了,会自动选新主吗

问题:想一个极端的情况,对MGR不是很熟悉,就是如果三个节点都offline 了,(反正不能用了)都让三个节点重启一下,这三个之间会自动选择一个master出来吗。

回答:这种情况下,相当于整个集群所有节点都离线了。这时候,需要将第一个加入集群的节点设置为引导模式:

root@GreatSQL> SET GLOBAL group_replication_bootstrap_group=ON;

再启动MGR服务(启动完成后记得将该选项改回 OFF)。

特别提醒:其他节点只需直接启动MGR服务即可,而不能执行上述引导节点的操作,否则会又启动(分裂)一个新MGR集群。

3. MGR监控关键点

我一般重点关注MGR的几个状态:

等待认证的事务队列

等待被apply的事务队列 执行下面的SQL来查看即可:

root@GreatSQL> select MEMBER_ID as id, COUNT_TRANSACTIONS_IN_QUEUE as trx_tobe_verified, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE as trx_tobe_applied, COUNT_TRANSACTIONS_CHECKED as trx_chkd, COUNT_TRANSACTIONS_REMOTE_APPLIED as trx_done, COUNT_TRANSACTIONS_LOCAL_PROPOSED as proposed from performance_schema.replication_group_member_stats;
+--------------------------------------+-------------------+------------------+----------+----------+----------+
| id                                   | trx_tobe_verified | trx_tobe_applied | trx_chkd | trx_done | proposed |
+--------------------------------------+-------------------+------------------+----------+----------+----------+
| 4b2b46e2-3b13-11ec-9800-525400fb993a |                 0 |                0 |    21384 |       40 |    21349 |
| 4b51849b-3b13-11ec-a180-525400e802e2 |                 0 |                0 |    21370 |    21374 |        0 |
| 4b7b3b88-3b13-11ec-86e9-525400e2078a |                 0 |                0 |    21255 |    21255 |        0 |
+--------------------------------------+-------------------+------------------+----------+----------+----------+

另外,也关注已获取的事务GTID及本地已执行的GTID之间的差距:

root@GreatSQL> select RECEIVED_TRANSACTION_SET from performance_schema.replication_connection_status union all select variable_value from performance_schema.global_variables where variable_name = 'gtid_executed';
+--------------------------------------------------------------------------------------------------------+
| RECEIVED_TRANSACTION_SET                                                                               |
+--------------------------------------------------------------------------------------------------------+
| 1c293e90-3bdc-11ec-bca1-525400e2078a:1-3822271:4800902-4800919,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1 |
|                                                                                                        |
| 1c293e90-3bdc-11ec-bca1-525400e2078a:1-3822271:4800902-4800919,
4b7b3b88-3b13-11ec-86e9-525400e2078a:1 |
+--------------------------------------------------------------------------------------------------------+

Enjoy MySQL :)

一周碎碎念,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公里。这是国庆节前手术后的第一次跑步,感觉恢复差不多了,跑下来总体感觉也还可以,配速和心率略微不太稳定外,步频倒还比较稳定。

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