（1）尝试删除

把mysql数据文件夹下的ib_logfile0和ib_logfile1这两个文件删除就可以了。

如果还不能解决问题，则

（2）修改mysql启动级别

在my.cnf中修改innodb_force_recovery=6， 然后启动mysql，正常应该能顺利启动。

然后用navicat备份所需的数据库；

停掉mysql

删掉iddata等文件，以默认的innodb_force_recovery=0启动

恢复备份的数据库

（

1、cd /var/lib rm -rf mysql/* systemctl start mysqld

2、初始密码在/var/log/mysqld.log这个文件里

3、输入命令：grep 'temporary password' /var/log/mysqld.log，可以直接获取密码。

（注：密码为冒号后面的所有字符！）

alter user 'root'@'localhost' identified by '密码';

use mysql;

update user set host='%' where user='root' limit 1;

flush privileges;

）

mysql从库开启crash-safe：

使用MySQL 8.0 克隆(clone)插件快速添加MGR节点
目录
一、MySQL 8.0.17的克隆clone简介
二、MGR现有环境
三、使用clone技术添加MGR节点
3.1 初始化新节点
3.2 新节点安装clone插件和组复制插件
3.3 新节点执行克隆任务
3.4 在原3节点执行修改参数
3.5 新节点启动MGR
四、总结
复制
一、MySQL 8.0.17的克隆clone简介
MySQL 8.0.17的克隆插件允许在本地或从远程 MySQL 实例在线克隆数据，从此搭建从库可以不再需要备份工具（PXB或mysqldump）来实现了。克隆数据是存储在 InnoDB 其中的数据的物理快照，其中包括库、表、表空间和数据字典元数据。克隆的数据包含一个功能齐全的数据目录，允许使用克隆插件进行 MySQL 服务器配置。

克隆插件支持两种克隆方式：

本地克隆：本地克隆操作将启动克隆操作的 MySQL 服务器实例中的数据克隆到同服务器或同节点上的一个目录里。

远程克隆：默认情况下，远程克隆操作会删除接受者(recipient)数据目录中的数据，并将其替换为捐赠者(donor)的克隆数据。（可选）您也可以将数据克隆到接受者的其他目录，以避免删除现有数据。

远程克隆操作和本地克隆操作克隆的数据没有区别，数据是相同的。克隆插件支持复制。除克隆数据外，克隆操作还从捐赠者中提取并传输复制位置信息，并将其应用于接受者，从而可以使用克隆插件来配置组复制或主从复制。使用克隆插件进行配置比复制大量事务要快得多，效率更高。
MySQL 8.0 clone插件提供从一个实例克隆数据的功能，克隆功能提供了更有效的方式来快速创建MySQL实例，搭建主从复制和组复制。本文介绍使用 MySQL 8.0 clone 插件快速添加组复制（MGR）节点的方法。
官网地址：https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html

二、MGR现有环境
搭建MGR环境请参考：【DB宝18】在Docker中安装使用MySQL高可用之MGR

现已有MGR集群，多主模式：

3 rows in set (0.00 sec)
复制
docker环境：

[root@docker35 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9dd3d6b221b0 mysql:8.0.20 "docker-entrypoint.s…" 3 months ago Up 10 minutes 33060/tcp, 0.0.0.0:33067->3306/tcp mysql8020mgr33067
189b5a889665 mysql:8.0.20 "docker-entrypoint.s…" 3 months ago Up 10 minutes 33060/tcp, 0.0.0.0:33066->3306/tcp mysql8020mgr33066
6ce08dd5dc84 mysql:8.0.20 "docker-entrypoint.s…" 3 months ago Up 10 minutes 33060/tcp, 0.0.0.0:33065->3306/tcp mysql8020mgr33065
复制
通过clone插件新加节点：172.72.0.18。

三、使用clone技术添加MGR节点
3.1 初始化新节点
mkdir -p /usr/local/mysql/lhrmgr18/conf.d
mkdir -p /usr/local/mysql/lhrmgr18/data

docker run -d --name mysql8020mgr33068 \
-h lhrmgr18 -p 33068:3306 --net=mysql-network --ip 172.72.0.18 \
-v /usr/local/mysql/lhrmgr18/conf.d:/etc/mysql/conf.d -v /usr/local/mysql/lhrmgr18/data:/var/lib/mysql/ \
-e MYSQL_ROOT_PASSWORD=lhr \
-e TZ=Asia/Shanghai \
mysql:8.0.20

cat > /usr/local/mysql/lhrmgr18/conf.d/my.cnf <<"EOF"
[mysqld]
user=mysql
port=3306
character_set_server=utf8mb4
secure_file_priv=''
server-id = 802033068
log-bin =
binlog_format=row
binlog_checksum=NONE
log-slave-updates=1
skip-name-resolve
auto-increment-increment=2
auto-increment-offset=1
gtid-mode=ON
enforce-gtid-consistency=on
default_authentication_plugin=mysql_native_password
max_allowed_packet = 500M
log_slave_updates=on

master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log=lhrmgr18-relay-bin-ip18

transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=OFF
loose-group_replication_local_address= "172.72.0.18:33064"
loose-group_replication_group_seeds= "172.72.0.15:33061,172.72.0.16:33062,172.72.0.17:33063,172.72.0.18:33064"
loose-group_replication_bootstrap_group=OFF
loose-group_replication_ip_whitelist="172.72.0.15,172.72.0.16,172.72.0.17,172.72.0.18"
report_host=172.72.0.18
report_port=3306

EOF

docker restart mysql8020mgr33068

docker ps
mysql -uroot -plhr -h192.168.1.35 -P33065 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33066 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33067 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33068 -e "select @@hostname,@@server_id,@@server_uuid"
mysql -uroot -plhr -h192.168.1.35 -P33065
mysql -uroot -plhr -h192.168.1.35 -P33066
mysql -uroot -plhr -h192.168.1.35 -P33067
mysql -uroot -plhr -h192.168.1.35 -P33068
docker logs -f --tail 10 mysql8020mgr33065
docker logs -f --tail 10 mysql8020mgr33066
docker logs -f --tail 10 mysql8020mgr33067
docker logs -f --tail 10 mysql8020mgr33068

复制
3.2 新节点安装clone插件和组复制插件
mysql -uroot -plhr -h192.168.1.35 -P33068

-- 安装MGR插件
INSTALL PLUGIN group_replication SONAME 'group_replication.so';

-- 安装clone插件(注意，需要在源MGR3个节点都安装)
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
复制
3.3 新节点执行克隆任务
-- 设置克隆源，将clone_valid_donor_list设置为MGR节点
SET GLOBAL clone_valid_donor_list = '172.72.0.15:3306';

-- 新节点开始克隆
CLONE INSTANCE FROM 'root'@'172.72.0.15':3306 IDENTIFIED BY 'lhr';

-- 由于是docker环境，所以需要重启容器
-- ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
docker restart mysql8020mgr33068

-- 查看克隆进度和状态
MySQL [(none)]> SELECT * FROM performance_schema.clone_status \G
1. row **

         ID: 1
        PID: 0
      STATE: Completed
 BEGIN_TIME: 2020-11-13 15:03:07.076
   END_TIME: 2020-11-13 15:04:31.224
     SOURCE: 172.72.0.15:3306
DESTINATION: LOCAL INSTANCE
   ERROR_NO: 0

ERROR_MESSAGE:

BINLOG_FILE: lhrmgr15-bin.000005

BINLOG_POSITION: 1235
GTID_EXECUTED: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-25
1 row in set (0.01 sec)

MySQL [(none)]> select

->   stage,
->   state,
->   cast(begin_time as DATETIME) as "START TIME",
->   cast(end_time as DATETIME) as "FINISH TIME",
->   lpad(sys.format_time(power(10,12) * (unix_timestamp(end_time) - unix_timestamp(begin_time))), 10, ' ') as DURATION,
->   lpad(concat(format(round(estimate/1024/1024,0), 0), "MB"), 16, ' ') as "Estimate",
->   case when begin_time is NULL then LPAD('%0', 7, ' ')
->   when estimate > 0 then
->   lpad(concat(round(data*100/estimate, 0), "%"), 7, ' ')
->   when end_time is NULL then lpad('0%', 7, ' ')
->   else lpad('100%', 7, ' ')
->   end as "Done(%)"
->   from performance_schema.clone_progress;

7 rows in set (0.01 sec)
复制
3.4 在原3节点执行修改参数
set global group_replication_group_seeds='172.72.0.15:33061,172.72.0.16:33062,172.72.0.17:33063,172.72.0.18:33064';
stop group_replication;
set global group_replication_ip_whitelist="172.72.0.15,172.72.0.16,172.72.0.17,172.72.0.18";
start group_replication;
复制
3.5 新节点启动MGR
-- 由于已有MGR集群是多主模式，需要先设置成多主模式
set global group_replication_single_primary_mode=OFF;
set global group_replication_enforce_update_everywhere_checks=ON;

-- 加入组复制
START GROUP_REPLICATION;

-- 查看组复制成员及状态
SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

4 rows in set (0.00 sec)

-- 新节点查询数据库

5 rows in set (0.01 sec
复制
至此，通过clone插件的方式添加MGR节点已成功，非常简单也非常快速。

四、总结
克隆技术的一些限制条件：

版本大于等于8.0.17且不支持跨版本。要求相同版本号，您无法MySQL 5.7和MySQL 8.0之间进行克隆，在8.0.19和8.0.20之间也不可以，而且要求版本>=8.0.17。

克隆操作期间不允许使用 DDL，允许并发DML。

两台机器具有相同的操作系统OS。同一平台同一架构，例如linux to windows、x64 to x32 是不支持。

两台MySQL实例具体相同的 innodb_page_size 和 innodb_data_file_path(ibdata文件名)

同一时刻仅仅允许有一个克隆任务存在

recipient 需要设置变量clone_valid_donor_list

max_allowed_packet 大于2M

doner的undo表空间文件名称不能重复

不会克隆my.cnf文件

不会克隆binlog二进制日志。

仅仅支持innodb引擎。不克隆其他存储引擎数据。MyISAM并且 CSV存储在包括sys模式的任何模式中的表都被克隆为空表。

捐赠者和接受者都需要安装克隆插件

捐赠者和接受者分别需要有至少BACKUP_ADMIN/CLONE_ADMIN权限的账号

不支持通过MySQL router连接到捐赠者实例。

默认情况下，克隆数据后会自动重新启动接受者 MySQL 实例。要自动重新启动，必须在接收方上提供监视进程以检测服务器是否已关闭。否则，在克隆数据后，克隆操作将停止并出现以下错误，并且关闭接受者 MySQL 服务器实例。此错误不表示克隆失败。这意味着必须在克隆数据后手动重新启动接受者的 MySQL 实例。

本文结束。

生产环境使用最新版本的xtrabackup版本，鉴于xtrabackup 8.0版本移除命令，推荐使用xtrabackup命令进行备份和还原。

安装

在percona官方下载centos版本的rpm包，使用yum安装（示例）：
yum -y localinstall percona-xtrabackup-80-8.0.1-2.alpha2.el7.x86_64.rpm
sudo yum install https://repo.percona.com/centos/7/RPMS/noarch/percona-release-0.1-8.noarch.rpm

sudo percona-release enable tools testing
yum install percona-xtrabackup

• 全量备份：

1.全量备份
xtrabackup --defaults-file=/etc/my.cnf --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --backup --target-dir=/data/backup/
或者：使用参数--datadir替换掉参数--defaults-file.
# xtrabackup --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --datadir=/data/crm/ --backup --target-dir=/data/backup/

2.数据恢复：
2.1停止掉运行的数据库实例：
# /etc/init.d/mysqld_multi stop 3310
2.2 准备：
xtrabackup --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --prepare --target-dir=/data/backup/
2.3 拷回数据：
xtrabackup --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --datadir=/data/crm --copy-back --target-dir=/data/backup/
2.3 修改目录属性启动数据库：
chown -R mysql.mysql /data/crm
chmod -R 755 /data/crm
2.4 启动数据库实例:
/etc/init.d/mysqld_multi start 3310

2.5 若有主从的问题可以查看备份目录下的文件：
# cat xtrabackup_binlog_pos_innodb
crm_bin.001282 1049711778

• 增量备份：

全量备份的目录为：mkdir -p /data/backup
增量备份的目录为： mkdir -p /data/backupIncr

0. 备份操作之前需要停止掉数据库：

1.备份操作：
1.1.全量备份：
xtrabackup --defaults-file=/etc/my.cnf --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --backup --parallel=3 --target-dir=/data/backup/
1.2.增量备份：
xtrabackup --defaults-file=/etc/my.cnf --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --backup --parallel=3 --target-dir=/data/backupIncr --incremental-basedir=/data/backup

2.恢复操作：
2.1 准备全备份的日志：
xtrabackup --prepare --apply-log-only --target-dir=/data/backup
2.2 准备增量备份的日志：
xtrabackup --prepare --apply-log-only --target-dir=/data/backup --incremental-dir=/data/backupIncr
2.3 全备份准备：
xtrabackup --prepare --target-dir=/data/backup
2.4 拷回数据：
xtrabackup --host=172.16.1.52 --user=root --password=xxxyyy --port=3310 --datadir=/data/crm --copy-back --target-dir=/data/backup/

2.5 修改数据目录的权限和属性：
chown -R mysql:mysql /data/crm
chmod -R 755 /data/crm

2.6 启动实例：
/etc/init.d/mysqld_multi start 3310

恢复过程说明：
1）解压数据备份

安装qpress软件
    rpm -ivh qpress-11.1.el7.x86_64.rpm
解压备份
    Cd /backup/Data/backup/xtrabackup/202042
    tar -xvf 192.168.138.2_41667_20201021_full.tar
    tar -xvf 192.168.138.2_41667_20201022_incre.tar
qpress解压数据文件
    cd /backup/Data/backup/xtrabackup/202042/41667/full
        (for bf in `find . -iname "*\.qp"` ; do echo $bf && qpress -d $bf $(dirname $bf) && rm -rf $bf ; done)
    cd /backup/Data/backup/xtrabackup/202042/41667/incre
        (for bf in `find . -iname "*\.qp"` ; do echo $bf && qpress -d $bf $(dirname $bf) && rm -rf $bf ; done)

2）合并备份

perpare全备
    innobackupex --apply-log --redo-only /backup/Data/backup/xtrabackup/202042/41667/full/
合并incre到全备
    innobackupex --apply-log --incremental-dir=/backup/Data/backup/xtrabackup/202042/41667/incre //backup/Data/backup/xtrabackup/202042/41667/full
perpare整个备份
    innobackupex --apply-log /backup/Data/backup/xtrabackup/202042/41667/full

3）恢复数据

停止数据库
    systemctl stop mysqld
清除数据文件目录数据
    cd /Data/mysql/
    rm -rf *
应用备份
    mv /backup/Data/backup/xtrabackup/202042/41667/full/* /Data/mysql
更改目录权限
    chown -R mysql.mysql /Data/mysql
重启数据库
    systemctl start mysqld

4）截取binlog日志

获得position起点
    cat /backup/Data/backup/xtrabackup/202042/41667/incre/xtrabackup_binlog_info 
    mysql-bin.002244    194    230f7b03-e281-11e9-a531-0894ef952262:1-7
登录源数据库服务器获取bin-log日志，拷贝日志至恢复测试服务器/home/pmoopr/目录
获得position终点
    mysqlbinlog mysql-bin.002244
    mysqlbinlog mysql-bin.002245
    mysqlbinlog mysql-bin.002246
    mysqlbinlog mysql-bin.002247
截取日志
    mysqlbinlog --skip-gtids --start-position=194 /home/pmoopr/mysql-bin.002244 >/backup/Data/backup/xtrabackup/202042/2244.sql
    mysqlbinlog --skip-gtids --start-position=194 /home/pmoopr/mysql-bin.002245 >/backup/Data/backup/xtrabackup/202042/2245.sql
    mysqlbinlog --skip-gtids --start-position=194 /home/pmoopr/mysql-bin.002246 >/backup/Data/backup/xtrabackup/202042/2246.sql
    mysqlbinlog --skip-gtids --start-position=194 /home/pmoopr/mysql-bin.002247 >/backup/Data/backup/xtrabackup/202042/2247.sql

5）应用日志

mysql -uroot -p
停止记录binlog日志
    set sql_log_bin=0;
应用日志
    source /backup/Data/backup/xtrabackup/202042/2244.sql
    source /backup/Data/backup/xtrabackup/202042/2245.sql
    source /backup/Data/backup/xtrabackup/202042/2246.sql
    source /backup/Data/backup/xtrabackup/202042/2247.sql
开启记录binlog日志
    set sql_log_bin=1;

sql 执行频率

一、通过 show status 命令了解各种sql的执行频率

mysql客户端连接成功后，通过show[session|global] status命令，可以查看服务器的状态，如果不加默认为session（session级为当前连接的统计结果，global级为自数据库上次启动到现在的统计结果）。
Eg: show status like 'Com_%';

com_xx表示每个xx语句的执行次数，通常着重看curd操作次数（这些参数适用于所有存储引擎）；

Com_insert：执行select操作的次数，一次查询只累加1；
Com_select：执行insert操作的次数，批量插入的insert操作只累加一次；
Com_delete：执行update操作次数，提交和回滚均会累加；
Com_update：执行delete操作次数。
针对innodb存储引擎的表操作，累加的算法比如：show status like 'Innodb_rows_%';

show status like 'connections';----- 试图连接mysql数据库的次数

show status like ‘uptime’;-- 服务器工作时间

show status like ‘slow_queries’; – 慢查询的次数

二、定位执行效率较低的sql语句

​ 通过慢查询日志定位哪些sql执行效率低下，用–log-slow-queries[=file_name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time 秒的sql语句的日志文件，具体可参看后面的日志管理部分。
​ 慢查询日志在查询结束以后才记录，所以在应用反正执行效率出现问题的时候查询慢查询日志并不能定位问题，可以使用show processlist命令查看当前mysql在进行的线程，包括线程的状态，是否锁表等，可以实时查看sql的执行情况，同时对一些锁表操作进行优化。

三、通过explain分析低效sql的执行计划

追查到效率低的sql后，可以通过explain或desc命令获取mysql如何执行select语句的信息，包括在select语句执行过程中表如何连接和连接的顺序，eg:统计某个email为租赁电影拷贝所支付的总金额，需要关联客户表customer和付款表payment,并且对付款金额amount字段做求和操作，相应sql的执行计划如下：
explain select sum(amount) from customer a ,payment b where 1=1 and a.customer_id=b.customer_id and email ='JANE.BENNETT@SAKILACUSTOMER.ORG'\G

下面对每个列进行简单说明：
select_type:表示select的类型，常见取值 simple(简单表，即不适用表连接或者子查询)，primary(主查询，即外层的查询)，union（union中的第二个或者后面的查询语句），subquery(子查询中的第一个select)等。
table：输出结果集的表。
possible_keys:表示查询时可能使用的索引，不表示出现在这里的就是表的全部索引。
key:表示实际使用的索引。
key_len：使用到索引字段的长度。
rows:扫描行的数量。
extra:执行情况的说明和描述，包含不适合在其他列中显示但是对执行计划非常重要的额外信息。

type:表示mysql在表中找到所需行的方式，或者叫访问类型，常见如下（性能由左至右由最差变道最好）：all 、 index 、 range 、 ref、 eq_ref 、 const,system 、 null