Mysql 显示 InnoDB 状态未在 Linux 上正确报告缓冲池统计信息

25-04-27 2

最近很多小伙伴都在问Mysql显示InnoDB状态未在Linux上正确报告缓冲池统计信息这两个问题，那么本篇文章就来给大家详细解答一下，同时本文还将给你拓展1-2【包子mysql系列】，对mysql的

最近很多小伙伴都在问Mysql 显示 InnoDB 状态未在 Linux 上正确报告缓冲池统计信息这两个问题，那么本篇文章就来给大家详细解答一下，同时本文还将给你拓展1-2 【包子 mysql 系列】，对 mysql 的 innoDB 加锁分析、13.4 mysql 用户管理 13.5 常用 sql 语句 13.6 mysql 数据库备份恢复答疑：xtrabackup 备份 innodb 引擎的数据库、CentOS 8 安装 MySQL 8.0 InnoDB Cluster 集群以及 MySQL-Router 8、error-mysql InnoDB: Error: "mysql"."innodb_table_stats等相关知识，下面开始了哦！

本文目录一览：

Mysql 显示 InnoDB 状态未在 Linux 上正确报告缓冲池统计信息
1-2 【包子 mysql 系列】，对 mysql 的 innoDB 加锁分析
13.4 mysql 用户管理 13.5 常用 sql 语句 13.6 mysql 数据库备份恢复答疑：xtrabackup 备份 innodb 引擎的数据库
CentOS 8 安装 MySQL 8.0 InnoDB Cluster 集群以及 MySQL-Router 8
error-mysql InnoDB: Error: "mysql"."innodb_table_stats

Mysql 显示 InnoDB 状态未在 Linux 上正确报告缓冲池统计信息

如何解决Mysql 显示 InnoDB 状态未在 Linux 上正确报告缓冲池统计信息

我们有多个运行 MysqL 5.7 的从站——一些在 Linux (CentOS 7) 上，一些在 Windows 上。我们正在尝试诊断一个问题，即我们的 linux 机器随机开始落后，没有长时间运行的查询或锁或写入和读取的急剧增加。

我们在 Linux 机器上的错误日志充满了“InnoDB：page_cleaner：1000ms 预期循环用了 x ms。设置可能不是最佳的。”消息。

这表明我们正在从缓冲池中清除大量脏页。

查看innodb状态时： SHOW ENGINE INNODB STATUS

我们的 Windows 框显示非零值：

然而，Linux 机器的缓冲池状态显示为 0.00 for youngs/s、non-youngs/s、reads/s 等，这是不正确的。

任何想法如何让 Linux 机器正确报告？

解决方法

将 lru_scan_depth（现在可能是 1024）降低到例如 20，可能有助于提高性能并使这些消息消失。（请报告您获得的结果。）

1-2 【包子 mysql 系列】，对 mysql 的 innoDB 加锁分析

innoDB 的事务，是基于锁来实现的，用到事务不自然就会用到锁，而如果对锁理解的不通透，很容易造成线上问题。

数据库加锁的分析，和事务的引擎，隔离级别，索引，主键索引都有关系，

如果去考虑引擎和各种隔离级别的话，就会很复杂了，所以下面都是基于 innoDB 和 RR 的隔离级别进行分析：

表结构：

内容：

1 , 根据主键更新

如果根据主键来行数

事务 A	事务 B
update user set name=''ce1'' where id=''1'';	update user set name=''ce3'' where Id=''3'';	同时执行，都成功
update user set name=''ce1'' where id=''1'';	update user set name=''ce3'' where userId=''10003'';	B 更新失败，直至：Lock wait timeout

结论，如果根据非主键来更新，会把整个表进行锁定，无法进行更新操作。

注：只要是根据主键索引来更新，哪怕事务 A 没命中主键，也不会锁定整个表

2，根据非索引非主键更新

事务 A

事务 B

update user set name=''ce1'' where userId=''10001'';

update user set name=''ce3'' where Id=''3'';

或者

update user set name=''ce3'' where userId=''10003''

都会失败，如果非索引，直接锁表

3，如果在 userId 列上加入普通唯一索引

修改成

再更新

事务 A

事务 B

update user set name=''ce1'' where userId=''10001'';

update user set name=''ce3'' where Id=''3'';

或者

update user set name=''ce3'' where userId=''10003''

都会成功，如果有唯一索引，也是能成功行数，互相不影响

4，如果在 userId 列上加入普通非唯一索引（重点探讨）

把 userId 改成非唯一索引：

记录内容如下：

+----+--------+------+

| id | userId | name |

+----+--------+------+

| 1 | 10001 | ce1 |

| 2 | 10002 | ce2 |

| 3 | 10001 | ce3 |

| 4 | 10004 | ce4 |

+----+--------+------+

再相同操作

事务 A	事务 B
update user set name=''ce1'' where userId=''10001'';	update user set name=''ce3'' where Id=''3'';	B 失误执行失败，显然 id=3 的这行也被锁住了

其实最终还是按主键锁住的记录 id=1 和 id=3 的记录

非唯一索引与普通索引，更一步的区别是 GAP 锁

gap 锁是用于解决幻读的存在，演示

把记录修改成，如：

id 为 pk. userId 为 Normal key

A 事务

B 事务

结果

begin;

update user set name=''ce22'' where userId=''100020'';

insert into user (userId,name) values(''100021'',''tttt'');

直至事务失败超时

1，首先 GAP 锁针对的是 insert 操作

2，当更新 userId=''100020'' 时，会锁住两边的记录区间，防止幻读的存在。

3，锁是作用在普通索引上，但由于索引是由 B + 树存储，那么锁住的是两边的区间，防止 insert

GAP 锁为什么不是锁住一条记录，而是锁住一个区间呢？

附上疑问： https://www.oschina.net/question/867417_2289606

其实：

GAP 锁是解决幻读存在的，如当 delete 时就必须锁住区间了

A 事务	B 事务
begin; delete from user where userId=''888888'';
	insert into user (userId,name) values(''100021'',''tttt'');	OK, 可以插入
	insert into user (userId,name) values(''100041'',''tttt'');	插入超时

可见，这个 GAP 锁，锁住的是 100040~ 无穷大的记录

死锁的产生分析：

1，两条语句产生的死锁

id = pk, userId= key

最简单的。两条语句互相更新等待

begin;

update user set name=''ce1'' where userId=''100010'';

begin;

update user set name=''ce2'' where userId=''100020'';

update user set name=''ce1'' where userId=''100010'';

最简单的死锁

2，由于 gap 锁，删除一台不存在的记录

如，先删除一条记录，然后插入一条记录，如果记录 GAP 锁冲突，两个事务容易互为死锁。如：

A 事务	B 事务
begin; delete from user where userId=''100020''; （Query OK, 1 row affected）	begin;
	delete from user where userId=''565656'';
insert into user (userId,name) values(''100041'',''tttt'');
	insert into user (userId,name) values(''100019'',''tttt'');

结果直接抛出：

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

分析：

A 事务 delete 加入 gap 锁【100010，100020】，第二段【100020，100030】

B 事务 delete 加入 gap 锁【100040，无穷大】

然后 A 事务插入，获取插入意向锁时 B 事务的 GAP 锁被阻塞

B 事务插入，获取插入意向锁时时被 A 事务的 GAP 锁阻塞

结果死锁

13.4 mysql 用户管理 13.5 常用 sql 语句 13.6 mysql 数据库备份恢复答疑：xtrabackup 备份 innodb 引擎的数据库

13.4 mysql 用户管理

场景，为了安全，新建的站点，创建新的用户，或者给予使用已有账户，给予权限

MySQL 创建用户以及授权

grant all on *.* to ''user1'' identified by ''passwd'';

grant all on *.* to ''user1''@''127.0.0.1'' identified by ''passwd'';

grant 授权
all （查看，创建，删除等等）
''user1''@''127.0.0.1'' 指定用户 @指定来源 IP （指定用户可以写 %，表示所有的 IP）如果指定了来源 IP，那么只能通过来源 IP 登录
. 所有库，所有表

命令输错，直接输入 “；” 分号退出

grant SELECT,UPDATE,INSERT on db1.* to ''user2''@''192.168.133.1'' identified by ''passwd'';

grant all on db1.* to ''user3''@''%'' identified by ''passwd'';

查看所有的授权

show grants;   //默认用root

show grants for user2@192.168.133.1;

13.5 常用 sql 语句

查看表的行数
select count (*) from mysql.user; // 库和标有个。分割

查看所有的内容

select * from mysql.db;

查看 db 库的所有内容

select db from mysql.db;

查看表，用户

select db,user from mysql.db;

模糊查询

select * from mysql.db where host like ''192.168.%'';

插入 1, ''abc'' 到 db1.t1 表

insert into db1.t1 values (1, ''abc'');

更改 db1.t1 的字符串为 name 的数据和字符串为 id 的数据

update db1.t1 set name=''aaa'' where id=1;

清空表数据

truncate table db1.t1;

drop 会把表的框架也丢掉

drop table db1.t1;

丢掉表

drop database db1;

myisam 引擎的库的好处是，能自动去统计行数

尽量少用 * 这样操作，如果是大表会很耗时

13.6 mysql 数据库备份恢复

备份库

mysqldump -uroot -p123456 mysql > /tmp/mysql.sql

恢复库 // 恢复是，必须保证目录一致

mysql -uroot -p123456 mysql < /tmp/mysql.sql

备份表

mysqldump -uroot -p123456 mysql user > /tmp/user.sql

恢复表

mysql -uroot -p123456 mysql < /tmp/user.sql

备份所有库

mysqldump -uroot -p -A >/tmp/123.sql

只备份表结构

mysqldump -uroot -p123456 -d mysql > /tmp/mysql.sql

myisam 常用于比较小的库进行备份，大数据的备份时间会很长

答疑：xtrabackup 备份 innodb 引擎的数据库

xtrabackup 只能用于备份 innodb 引擎的数据库，但也想备份 myisam 引擎的需要通过脚本 perl

假设：数据库已经运行

ls/ data/mysql/ 查看MySQL下有多少个数据

使用

xtrabackup 会把磁盘的数据块备份一份

这个工具用 perl 写的

安装一个 yum 源

rpm -ivh http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm

安装 "percona-xtrabackup" 包

使用命令备份

innobackupex

备份前需要创建一个用户，在 mysql 里面创建，并授权备份权限

grant RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ''bakuser''@localhost identified by ''aming-linux'';

创建完需有一个刷权限的操作

flush privileges;

创建备份的目录

mkdir /data/backup

开始备份

innobackupex --defaults-file=/etc/my.cnf --user=bakuser --password=''aming-linux'' -S /tmp/mysql.sock  /data/backup
             指定默认的配置文件            指定用户            指定密码             指定sock           指定备份的目录

每次备份都会生成一个目录，目录大小和库文件大小差不多

恢复数据

== 首先停掉 mysql 服务 ==

清空 mysql 目录下原有数据

初始化

innobackuupex --user-memory=512M --apply-log [备份的时间目录]
              指定恢复数据的内存            指定恢复日志

指定恢复数据的内存，有助于对库的备份减少时间，但前提需要考虑内存情况

例：

innobackupex --use-memory=512M --apply-log 2017-08-22_20-44-37

恢复

nnobackupex --defaults-file=/etc/my.cnf --copy-back  .[备份的时间目录].
               指定默认的配置文件            指定恢复

例：

innobackupex --defaults-file=/etc/my.cnf --copy-back ./2017-08-22_20-44-37/

恢复日志就是 backup 下的备份的时间的目录

mysql 真正存储的数据是 ibdatal
备份数据的时候，会锁表

CentOS 8 安装 MySQL 8.0 InnoDB Cluster 集群以及 MySQL-Router 8

一.安装环境准备
CentOS-8.1.1911
MySQL-8.0.19
MySQL-shell8.0.19
Mysql-router8.0.19

1.服务器环境准备，(集群控制和路由器服务器这里只部署一台用以测试，生产环境中和应用服务器部署在一起)
MySQL 8 数据库 - 1                               IP:192.168.56.21         安装内容：CentOS-8.1.1911 、 MySQL-8.0.19
MySQL 8 数据库 - 2                               IP:192.168.56.22         安装内容：CentOS-8.1.1911 、 MySQL-8.0.19
MySQL 8 数据库 - 3                               IP:192.168.56.23         安装内容：CentOS-8.1.1911 、 MySQL-8.0.19
MySQL 8 集群控制和路由服务器           IP:192.168.56.31         安装内容：CentOS-8.1.1911 、 MySQL-shell8.0.19 、 Mysql-router8.0.19

2.设置 ip 地址
vi /etc/sysconfig/network-scripts/ifcfg-enp0s8
修改 IPADDR 后边的值为内网 IP 地址的值 IP:192.168.56.21 、 192.168.56.22 、 192.168.56.23 、 192.168.56.31 、 192.168.56.32
让 IP 地址生效
nmcli connection reload
reboot

3.调整操作系统 SELinux 和 firewall 的安全策略
SELinux 配置很复杂，所有服务器关闭 SELinux
setenforce 0
vi /etc/selinux/config
SELINUX=disabled
注意：如果一定要使用 SELinux，则可尝试以下步骤
1).安装 semanage 包
yum provides semanage # 查找所在的包，得到结果 policycoreutils-python-utils-2.9-3.el8_1.1.noarch
yum install -y policycoreutils-python-utils
1).查看 MySQL 当前配置为使用哪些端口
semanage port -l | grep mysqld
2).组复制通信端口为 33061，则通过发出以下命令将其添加到 SELinux 允许的通信端口中
semanage port -a -t mysqld_port_t -p tcp 33061
3).此外，还需要设置 seboolean
setsebool -P mysql_connect_any=ON

在 3 台 MySQL 数据库服务器 firewall 防火墙中放开 mysql 的 3306 端口和准备制作集群的 33061 端口，经过大量测试，集群应该只需要 tcp 协议支持
firewall-cmd --permanent --zone=public --add-port=3306/tcp
firewall-cmd --permanent --zone=public --add-port=33061/tcp
# 删除的命令为： firewall-cmd --permanent --zone=public --remove-port=33061/tcp
# 列出所有开放端口的命令：firewall-cmd --zone=public --list-ports
firewall-cmd --reload

4.MySQL 8 的安装和配置不说了，网上很多，我是使用 yum 安装的，做好基本的初始化就可以7.3台 MySQL 数据库服务器修改 mysql 8 的配置文件 /etc/my.cnf
vi /etc/my.cnf
在 [mysqld] 节点中加入 21、22、23，以下以 21 为例：
---------------------------------------------------------------------------------------------------------
[mysqld]
default-authentication-plugin=mysql_native_password

table_open_cache=4000
max_connections=20000

skip_ssl

# 数据文件路径
datadir=/var/lib/mysql
# 启动 socket 连接后存放 socket 文件的位置
socket=/var/lib/mysql/mysql.sock

# 错误日志文件
log-error=/var/log/mysqld.log
# MySQL 进程ID保存文件
pid-file=/var/run/mysqld/mysqld.pid

# 开启 binlog 日志，默认在 /var/lib/mysql/ 文件夹下，名称前缀为 mysql-bin，根据日志文件默认大小生成 mysql-bin.000001，mysql-bin.000002，mysql-bin.000003......等日志文件
log-bin=mysql-bin
# 日志使用 ROW 格式
binlog_format=ROW

# 这个配置没有的时候之前集群经常无故节点宕机

# relay log很多方面都跟binary log差不多，是从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后SQL线程会读取relay-log日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致， relay-log 参数是存放的位置，relay-log-index定义relay_log的位置和名称，一般和relay-log在同一目录

relay-log=/data/mysql/bin-log/relay-log
relay-log-index=/data/mysql/bin-log/relay-log-index

# binlog最大大小，一般来说设置为512M或者1G，但不能超过1G
max_binlog_size=1G
# binlog缓存大小
binlog_cache_size=8m
# 最大binlog缓存大小
max_binlog_cache_size=256M
# 版本 8 后新增的（以秒为单位），8.0.4之前默认值为0，8.0.11之后为2592000也就是30天，8.0 以前的是 expire_logs_days（以天为单位），如果有了 binlog_expire_logs_seconds 不会再执行 expire_logs_days
binlog_expire_logs_seconds=2592000
# 默认值为MINIMAL,可以设置为FULL，此参数用于控制row格式下binlog中表的元数据数量，设置为MINMAL时记录符号标记、列字符集和空间类型，设置为FULL时会记录表所有的元数据，例如列名、枚举或集合所有的值、主键信息等等。
# binlog_row_metadata=MINIMAL
# 默认值为25000，可以设置为0-1000000之间的任意整数。8.0基于WriteSet进行并行复制时，WriteSet是一个hash数组，binlog_transaction_dependency_history_size值就是这个hash数组的最大值。
# binlog_transaction_dependency_history_size=25000
# 默认值为COMMIT_ORDER，也可以设置为WRITESET、WRITESET_SESSION。此参数用于主库决定事务间在从库进行多线程复制的依赖模式。COMMIT_ORDERE：根据主库事务提交时间戳进行并行，也就5.7的GroupCommit；WRITESET：根据WriteSet进行并行，只要是不在同一个队列里的都可以并行；WRITESET_SESSION: 根据WriteSet进行并行，但相同session的事务不会并行。
binlog_transaction_dependency_tracking=COMMIT_ORDER

#数据库表名大小写不敏感（否则MyCat中间件会失效）
#lower_case_table_names = 1

# 开启慢查询日志
slow_query_log=ON
# 慢查询日志位置，5.6版本以下是 log-slow-queries
slow_query_log_file=/var/lib/mysql/mysqld-slow.log # 如果设置该值，总会报错 ERROR [InnoDB] Only one log file found，还没找到原因，可以在 mysql 命令下通过 show variables like ''%slow_query%''; 命令查找文件存放的位置，默认位置是 /var/lib/mysql/服务器名称-slow.log
# 慢查询时间设置，当查询时间多于设定的时间值时，记录日志，以秒为单元
long_query_time=2
# 记录没有使用索引的查询日志 ON 或 OFF
log_queries_not_using_indexes=OFF

#修改当前会话时区
default-time_zone=''+8:00''
#设置数据库字符集为utf8mb4（mysql中真正的UTF8）
character-set-server=utf8mb4
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

# 这里的 id 号码要根据服务器变化，服务器序号，对做集群时很有用
server_id=21
# 开启GTID复制功能，如果开启本项，log_slave_updates 和 log_bin 也必须开启
gtid_mode=ON
# 因为开启grid_mode以后，许多MySQL的SQL和GTID是不兼容的，这里强制兼容
enforce_gtid_consistency=1
# 将 master.info 保存在表中，默认是Myisam引擎，官方建议用
master_info_repository=TABLE
# 将 relay.info 保存在表中，默认是Myisam引擎，官方建议用
relay_log_info_repository=TABLE
# 主从同步的时候不生成checksum，这样就可以兼容旧版本的mysql
binlog_checksum = NONE
# 控制主从复制的时候是否把操作都写入 binlog
log_slave_updates = ON
# 禁用域名解析，提高服务器间访问速度
skip-name-resolve
# 禁用域名解析后需要给集群通知本机地址，如果没有该值，使用 skip-name-resolve 不起作用，必须要在操作系统 hosts 中配置集群节点的 host 名称才能识别每台服务器并加入集群
report-host=''192.168.56.21''

# 以下是组复制集群的基础配置
disabled_storage_engines=BLACKHOLE,FEDERATED,CSV,ARCHIVE # 未包含 MyISAM 因为 MySQL 本身一些表通过该引擎存储
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="901b7ca6-926e-4fa6-aad5-fe86a05e6ca5"

# 控制是否集群启动后随即开始复制 off 或 on
loose-group_replication_start_on_boot=on
loose-group_replication_local_address= "192.168.56.21:33061" # 这里的 IP 地址要根据服务器变化
loose-group_replication_group_seeds= "192.168.56.21:33061,192.168.56.22:33061,192.168.56.23:33061"
loose-group_replication_bootstrap_group=off
loose-group_replication_ip_whitelist="192.168.56.0/24"

# 该项控制集群是否启用单主节点模式，最好设置为单主，多主脑裂严重
loose-group_replication_single_primary_mode=ON
loose-group_replication_enforce_update_everywhere_checks=OFF

# 此参数设置为ON时，MySQL会根据检测到的内存大小设置innodb_buffer_pool_size、innodb_log_file_size、innodb_flush_method三个参数。有了这个参数我们就不用再写脚本根据内存大小去修改配置文件的这三个参数了，运维自动化又省了一步。
# 当服务器MySQL与其他应用共享服务器内存时建议设置为OFF。那么久可以按以下策略设置其它几个参数
# innodb_buffer_pool_size
# -------------------------------------------------------------------------------------
# 检测到的服务器内存设置缓存的大小
# < 1G 128MiB (innodb_buffer_pool_size 的默认值)
# <= 4G 检测到的服务器内存 * 0.5
# > 4G 检测到的服务器内存 * 0.75
# innodb_log_file_size
# -------------------------------------------------------------------------------------
# 检测到的服务器内存设置缓存的大小
# < 1GB 48MiB (innodb_log_file_size 的默认值)
# <= 4GB 128MiB
# <= 8GB 512MiB
# <= 16GB 1024MiB
# > 16GB 2048MiB
# innodb_flush_method
# 当开启 innodb_dedicated_server 时，刷盘方式会采用O_DIRECT_NO_FSYNC ，O_DIRECT_NO_FSYNC 不可用时将会采用默认的刷盘方式。需要注意的是，目前在linux中当文件大小发生变化时，O_DIRECT_NO_FSYNC 可能会导致系统hung住，因此不建议在linux中采用该刷盘方式。
# innodb_dedicated_server=ON
# 注意：添加 innodb_dedicated_server 参数会一直报下边的错误，需要删除 /var/lib/mysql 文件夹下以 ib_logfile 开头的文件，具体原因一直都没有找到，使用文件夹和文件赋权都不起作用
# [ERROR] [MY-012961] [InnoDB] Only one log file found
---------------------------------------------------------------------------------------------------------

5.3台 MySQL 数据库服务器的 mysql 命令下创建组复制账户 cluster，示例命令中我是把密码规则设置为简单的了，生产环境最好不要设置 global validate_password.policy 和 global validate_password.length 两个参数
使用 root 登录 mysql
mysql -uroot -p
set sql_log_bin=0;
set global validate_password.policy=0; # 别在生产环境配置
set global validate_password.length=5; # 别在生产环境配置
create user ''cluster''@''%'' identified by ''binux''; # 如果创建错了用命令删除 drop user ''cluster''@''%'';
grant all privileges on *.* to ''cluster''@''%'' with grant option; # 如果授权错了，使用命令收回 revoke all privileges on *.* from ''cluster''@''%'';
flush privileges;
set sql_log_bin=1;

二.集群环境搭建
1.在管理和路由服务器上准备安装 mysql-shell
下载 mysql-shell 8
yum -y localinstall mysql-shell-8.0.19-1.el8.x86_64.rpm

2.设置本机集群实例，命令是 mysqlsh 命令，里面用的都是 JavaScript 语法
选择一台节点制作就行，这里使用 192.168.56.21
mysqlsh --log-level=DEBUG3

顺序应该是
1).检查每个节点是否可用加入集群的状态，是否能够加入，能够加入会输出 OK，如果已经加入会给出提示
dba.checkInstanceConfiguration(''cluster@192.168.56.21:3306'');
dba.checkInstanceConfiguration(''cluster@192.168.56.21:3306'');
Please provide the password for ''cluster@192.168.56.21:3306'': *****
Save password for ''cluster@192.168.56.21:3306''? [Y]es/[N]o/Ne[v]er (default No):Y
The instance ''mic21:3306'' is valid to be used in an InnoDB cluster.
{
"status": "ok"
}

dba.checkInstanceConfiguration(''cluster@192.168.56.22:3306'')
Please provide the password for ''cluster@192.168.56.22:3306'': *****
Save password for ''cluster@192.168.56.22:3306''? [Y]es/[N]o/Ne[v]er (default No):Y
The instance ''mic22:3306'' is valid to be used in an InnoDB cluster.
{
"status": "ok"
}

dba.checkInstanceConfiguration(''cluster@192.168.56.23:3306'')
Please provide the password for ''cluster@192.168.56.23:3306'': *****
Save password for ''cluster@192.168.56.23:3306''? [Y]es/[N]o/Ne[v]er (default No):Y
The instance ''mic23:3306'' is valid to be used in an InnoDB cluster.
{
"status": "ok"
}

2).配置每个节点的实例入集群前的配置
dba.configureLocalInstance(''cluster@192.168.56.21'');
dba.configureLocalInstance(''cluster@192.168.56.22'');
dba.configureLocalInstance(''cluster@192.168.56.23'');

3).连接到其中一个节点，准备创建集群，这里连接 192.168.56.21
shell.connect(''cluster@192.168.56.21:3306'')

4).创建名称为 micCluster 的集群
var cluster = dba.createCluster(''micCluster'') # 设置自己的群名称，为这里是 micCluster
如果创建成功，则会显示成功，但至少需要三台服务器的提示
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.At least 3 instances are needed for the cluster to be able to withstand up to one server failure.

5).加入其它节点
加入其它两个节点
cluster.addInstance(''cluster@192.168.56.22:3306'')
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
输入 C ，加入成功后会出现以下成功提示：
The instance ''192.168.56.22:3306'' was successfully added to the cluster.

cluster.addInstance(''cluster@192.168.56.23:3306'')
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
输入 C ，加入成功后会出现以下成功提示：
The instance ''192.168.56.23:3306'' was successfully added to the cluster.

6).检查集群状态，在输出的内容中应该三台节点已经全部加入集群了
cluster.status()

7).进一步检查每个节点的状态，这个时候应该提示已属于某个集群的提示 Cluster.checkInstanceState: The instance ''192.168.56.21:3306'' already belongs to the cluster: ''default''. (RuntimeError)
cluster.checkInstanceState(''cluster@192.168.56.21:3306'')
cluster.checkInstanceState(''cluster@192.168.56.22:3306'')
cluster.checkInstanceState(''cluster@192.168.56.23:3306'')
可以退出 mysqlsh 命令了，输入 \q 即可退出

8).在数据库命令状态也可以验证集群
mysql -uroot -p
select * from performance_schema.replication_group_members;
查看主节点是哪一台：
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = ''group_replication_primary_member'';
接下来关闭主节点，在通过查询语句查看，应该能看到主节点已经变化了，这样就能初步验证集群生效了

9).如果整个集群关闭后，可以在 mysqlsh 命令下执行重启集群方法
dba.rebootClusterFromCompleteOutage(''micCluster'');
重启集群的时间会很长，因为会把几个节点的所有状态都检查并重启，很耗时
Reconfiguring the cluster ''micCluster'' from complete outage...

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

NOTE: Cancelling active GR auto-initialization at mic21:3306
Disabling super_read_only mode on instance ''mic21:3306''.
The cluster was successfully rebooted.

10).如果中间有哪台因为各种原因脱离集群后，重新加入的命令为，
cluster.rejoinInstance(''cluster@192.168.56.22'')

3.移除整个集群具体步骤
1).连接集群
shell.connect(''cluster@192.168.56.21:3306'')
2).获得集群
var cluster = dba.getCluster(''micCluster'')
3).移除节点
cluster.removeInstance(''cluster@192.168.56.22:3306'',{force:true})
4).解散集群
cluster.dissolve({force:true})
5).删除集群schema
dba.dropMetadataSchema();
6).在各节点清除集群残存数据
mysql -uroot -p
stop group_replication;
reset master; #清空日志，确保和从库的表没有冲突奥
reset slave;

4.常见状态、参数、命令
节点点状态     状态描述
ONLINE                    节点状态正常。
OFFLINE                     实例在运行，但没有加入任何Cluster。
RECOVERING     实例已加入Cluster，正在同步数据。
ERROR                     同步数据发生异常。
UNREACHABLE     与其他节点通讯中断，可能是网络问题，可能是节点crash。
MISSING                     节点已加入集群，但未启动group replication

集群状态                                     状态描述
OK                                     所有节点处于online状态，有冗余节点。
OK_PARTIAL                     有节点不可用，但仍有冗余节点。
OK_NO_TOLERANCE     有足够的online节点，但没有冗余，例如：两个节点的Cluster，其中一个挂了，集群就不可用了。
NO_QUORUM                     节点处于online状态，但达不到法定节点数，此状态下Cluster无法写入，只能读取。
UNKNOWN                     不是online或recovering状态，尝试连接其他实例查看状态。
UNAVAILABLE                     组内节点全是offline状态，但实例在运行，可能实例刚重启还没加入Cluster

mysqlsh常用命令 (mysqlsh的JS语法)
dba.checkInstanceConfiguration("cluster@192.168.56.21:3306")     #检查节点配置实例，用于加入cluster之前
dba.rebootClusterFromCompleteOutage(''micCluster'');        #重启
dba.dropMetadataSchema();                                #删除schema
var cluster = dba.getCluster(''micCluster'')                #获取当前集群
cluster.checkInstanceState("cluster@192.168.56.21:3306")         #检查cluster里节点状态
cluster.rejoinInstance("cluster@192.168.56.21:3306")             #重新加入节点，我本地测试的时候发现rejoin一直无效，每次是delete后
addcluster.dissolve({force：true})                       #删除集群
cluster.addInstance("cluster@192.168.56.21:3306")                #增加节点
cluster.removeInstance("cluster@192.168.56.21:3306")             #删除节点
cluster.removeInstance(''cluster@192.168.56.21'',{force:true})    #强制删除节点
cluster.dissolve({force:true})                           #解散集群
cluster.describe();                                      #集群描述

5.常见故障处理
问题：节点服务器重启后未加入集群（重新加入集群）（多出现主节点）
现象： "status": "(MISSING)"
执行cluster.rejoinInstance
处理：
shell.connect(''cluster@192.168.56.21:3306'');
cluster=dba.getCluster();
cluster.rejoinInstance("cluster@192.168.56.22:3306")

问题：集群中所有服务器重启，所有节点都offline，直接获取集群信息失败
查询数据库SELECT * FROM performance_schema.replication_group_members;
仅显示单机 ''MEMBER_STATE'' = ''offline''
使用SELECT clusters.cluster_id,clusters.cluster_name from mysql_innodb_cluster_metadata.clusters活着集群名称
执行rebootClusterFromCompleteOutage命令，恢复集群
处理：
shell.connect(''cluster@192.168.56.21:3306'');
dba.rebootClusterFromCompleteOutage(''micCluster'');

问题：集群创建中如果中途退出，比如创建集群后退出、少于3台节点就退出，但组复制在 mysql 节点中已开始运行，那下次进去想获得集群就会报错
Dba.getCluster: This function is not available through a session to a standalone instance (RuntimeError)
需要在 mysql 命令下执行对组复制的关闭开关，在创建集群的节点执行就可以
mysql> STOP GROUP_REPLICATION;

问题：如果节点是虚拟机复制的，那么在 msyql 安装目录下的 auto.cnf 文件中的 uuid 是一样，这样会报错：Cluster.addInstance: Cannot add an instance with the same server UUID (b9db0e3a-6529-11ea-868c-080027862089) of an active member of the cluster ''mic22:3306''. Please change the server UUID of the instance to add, all members must have a unique server UUID. (RuntimeError)
cd /var/lib/mysql
mv /var/lib/mysql/auto.cnf /var/lib/mysql/auto.cnf.bk
systemctl restart mysqld

问题：数据库不支持配置文件中的大小写配置：Different lower_case_table_names settings for server (''1'') and data dictionary (''0'')
如果在配置文件配置前启动了 mysql ，然后配置文件中的 lower_case_table_names=1 设置会报以下错误，
原因是只有在初始化的时候设置 lower_case_table_names=1才有效，比如： --initialize --lower-case-table-names=1

中间有什么异常去查看做节点那台服务器上 MySQL 日志文件： cat /var/log/mysqld.log

6.其它注意项
单主模式和多主模式注意
多主模式下：
loose-group_replication_single_primary_mode = off
操作流程：业务端连接IP处理 -> GROUP内成员逐个依次主动退出GROUP （全部退出才行）-> 关闭 group_replication_single_primary_mode参数-> 逐个启动GROUP内的SERVER
Set global group_replication_single_primary_mode=off

做组复制的 mysql 8 必须满足几个条件
1.必须是 InnoDB 存储引擎，可以在配置文件[mysqld]中禁用其它引擎 disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
2.每个表都要有主键
3.需要按以下配置进行设置
1).开启二进制日志文件[mysqld]
log_bin[=log_file_name]，可以不写文件路径，也可以设置你的路径，不写路径会直接存在数据文件同目录
2).开启从机更新日志[mysqld]，默认情况下，此选项处于启用状态
log-slave-updates[={OFF|ON}]
3).二进制日志行格式需要设置为行 row [mysqld]
binlog format=row
组复制依赖于基于行的复制格式，这样才能在服务器之间一致的传送数据，以检测在组中不同服务器上并发执行的事务之间的冲突。从MySQL 8.0.19开始，REQUIRE_ROW_FORMAT设置会自动添加到组复制的通道中，以便在应用事务时强制使用基于行的复制。
4).关闭二进制日志的校验 [mysqld]
binlog checksum=NONE
由于复制事件校验和的设计限制，组复制无法使用它们，必须禁用。
5).开启全局事务标识符[mysqld]
gtid_mode=ON
组复制使用全局事务标识符精确跟踪每个服务器实例上已提交的事务，从而能够推断哪些服务器已执行可能与其他已提交事务冲突的事务。换句话说，显式事务标识符是框架的一个基本部分，可以确定哪些事务可能发生冲突。
6).设置主机和中继日志复制信息的存储方式
master_info_repository=TABLE #主机信息存储在表中
relay_log_info_repository=TABLE #中继日志信息存储在表中
复制应用程序需要将主信息和中继日志元数据写入mysql.slave_master_info和mysql.slave_relay_log_info系统表。这确保了组复制插件对复制元数据具有一致的可恢复性和事务管理。在MySQL 8.0.2中，这些选项默认设置为TABLE，在MySQL 8.0.3中，不推荐使用文件设置。
7).事务写入集提取设置
transaction-write-set-extraction=XXHASH64
这样在收集行以将它们记录到二进制日志时，服务器也会收集写集。写集基于每一行的主键，是一个简单紧凑的标记视图，它唯一地标识了更改的行。然后使用此标记检测冲突。默认情况下，此选项处于启用状态。
8).二进制日志依赖项跟踪设置
binlog_transaction_dependency_tracking=WRITESET_SESSION
根据组的工作负载，设置binlog_transaction_dependency_tracking=WRITESET_SESSION可以提高组成员的性能。当从中继日志应用事务时，组复制在认证后执行其自己的并行化，与binlog_transaction_dependency_tracking设置的值无关。但是，binlog_transaction_dependency_tracking的值确实会影响事务如何写入组复制成员上的二进制日志。这些日志中的依赖关系信息用于帮助从提供者的二进制日志进行状态转移以进行分布式恢复的过程，该过程在成员加入或重新加入组时进行。
9).默认表加密
default-table-encryption
所有组成员上的默认表加密值相同。只要所有成员的设置相同，默认架构和表空间加密可以是启用（ON）或禁用（OFF，默认值）
10).小写表名设置
lower-case-table-names=1
在所有组成员上将小写表名设置为相同的值。对于使用InnoDB存储引擎，设置1是正确的，这是组复制所必需的。请注意，此设置并非所有平台上的默认设置。
11).多线程应用设置
slave_preserve_commit_order=1
slave_parallel_type=LOGICAL_CLOCK
组复制成员可以配置为多线程从机，从而使事务能够并行应用。从属并行工作线程的非零值启用成员上的多线程应用程序，最多可以指定1024个并行应用程序线程。设置slave_preserve_commit_order=1可确保并行事务的最终提交顺序与原始事务的顺序相同，这与组复制所需的顺序相同，后者依赖于围绕确保所有参与成员以相同顺序接收和应用提交的事务而构建的一致性机制。最后，设置slave_parallel_type=LOGICAL_CLOCK是必需的，它指定用于决定哪些事务允许在slave上并行执行的策略，slave_preserve_commit_order=1。设置slave_parallel_workers=0将禁用并行执行，并为slave提供一个applier线程，而不提供协调线程。使用该设置时，slave_parallel_type和slave_preserve_commit_order选项无效，将被忽略。
4.自 8.0.17 版本开始， server_id 必须是唯一的，否则会报错。
12).如果在 mysql 配置文件中未禁用 DNS 域名配置，也就是没有配置 skip-name-resolve 和 report-host=''192.168.56.21''，那就需要设置每台节点服务器的 host 用以通过 DNS 识别每台服务器，每台服务器中设置 host 名称的命令参照如下：
nmcli general hostname mic21
systemctl restart systemd-hostnamed
设置完后在每台服务器节点的 hosts 文件中加入域名和 IP 地址的对应关系，例如：
cp /etc/hosts /etc/hosts.bak
vi /etc/hosts
192.168.56.21 mic21
192.168.56.22 mic22
192.168.56.23 mic23

三.路由安装配置
1.在管理和路由服务器上准备安装 mysql-router
下载 mysql-router 8
yum -y localinstall mysql-router-community-8.0.19-1.el8.x86_64.rpm
注意：Router与应用程序最好位于同一主机上。
安装完成后使用命令验证
mysqlrouter --help

2.为 mysql-router 进行启动配置，有两种方式实现配置：

方式1：使用默认安装目录的配置文件进行配置并启动
这种方式会在配置文件中写死路由访问的IP地址先后顺序，根据路由规则进行访问。
可以通过 mysqlrouter --help 命令查看默认的配置文件路径，本文中使用的 mysql-router 版本在 CentOS 中安装后的默认配置文件路径为 /etc/mysqlrouter/mysqlrouter.conf
我的配置策略为：
1.配置一个读写端口，采用轮行方式，依次对 192.168.56.21、192.168.56.22、192.168.56.23 进行可用性探测，哪个可用用哪个做写入，然后集群会同步至其他服务器
配置文件如下
# 考虑一般都是第一台 192.168.56.21 是主节点，在另外两个节点 192.168.56.22、192.168.56.23 中进行负载均衡的读操作
--------------------------------------------------------------------------------------
[DEFAULT]
logging_folder = /var/log/mysqlrouter
runtime_folder = /var/run/mysqlrouter
config_folder = /etc/mysqlrouter

[logger]
level = INFO

# If no plugin is configured which starts a service, keepalive
# will make sure MySQL Router will not immediately exit. It is
# safe to remove once Router is configured.
[keepalive]
interval = 60

[routing:micCluster_rw]
bind_address=0.0.0.0
bind_port=6446
destinations=192.168.56.21:3306,192.168.56.22:3306,192.168.56.23:3306
routing_strategy=first-available

[routing:micCluster_ro]
bind_address=0.0.0.0
bind_port=6447
destinations=192.168.56.22:3306,192.168.56.23:3306
routing_strategy=round-robin
--------------------------------------------------------------------------------------
修改 mysqlrouter 的服务启动文件，主要是要把里面启动的用户 mysqlrouter 和用户组 mysqlrouter 给去掉，以便让 root 权限能够启动
vi /usr/lib/systemd/system/mysqlrouter.service
--------------------------------------------------------------------------------------
[Unit]
Description=MySQL Router
After=syslog.target
After=network.target

[Service]
Type=simple
#User=mysqlrouter
#Group=mysqlrouter

PIDFile=/var/run/mysqlrouter/mysqlrouter.pid

ExecStart=/usr/bin/mysqlrouter -c /etc/mysqlrouter/mysqlrouter.conf

PrivateTmp=true

[Install]
WantedBy=multi-user.target
--------------------------------------------------------------------------------------
保存并重启加载 systemctl 使修改生效
systemctl daemon-reload
启动服务
systemctl enable mysqlrouter
systemctl start mysqlrouter

方式二：使用 mysqlrouter 的初始化命令在我们自己定义的文件夹中生成一套完整的配置内容，包括配置文件，使用新的配置文件进行命令启动。该方式会自动获得集群的主节点、副节点进行路由。
我们设定 /opt/mysqlrouter 文件夹为新的全套配置文件位置，执行以下命令
mysqlrouter --bootstrap cluster@192.168.56.21:3306 --directory /opt/mysqlrouter --conf-use-sockets --force --user=root
如果成功，会给出以下成功内容
----------------------------------------------------------------------
Please enter MySQL password for cluster:
# Bootstrapping MySQL Router instance at ''/opt/mysqlrouter''...

- Creating account(s) (only those that are needed, if any)
- Verifying account (using it to run SQL queries that would be run by Router)
- Storing account in keyring
- Adjusting permissions of generated files
- Creating configuration /opt/mysqlrouter/mysqlrouter.conf

# MySQL Router configured for the InnoDB Cluster ''micCluster''

After this MySQL Router has been started with the generated configuration

$ mysqlrouter -c /opt/mysqlrouter/mysqlrouter.conf

the cluster ''micCluster'' can be reached by connecting to:

## MySQL Classic protocol

- Read/Write Connections: localhost:6446, /opt/mysqlrouter/mysql.sock
- Read/Only Connections: localhost:6447, /opt/mysqlrouter/mysqlro.sock

## MySQL X protocol

- Read/Write Connections: localhost:64460, /opt/mysqlrouter/mysqlx.sock
- Read/Only Connections: localhost:64470, /opt/mysqlrouter/mysqlxro.sock
----------------------------------------------------------------------
内容中的 /opt/mysqlrouter/mysqlrouter.conf 就是新的配置文件的位置，启动时需要用这个位置
新的配置文件内容如下：
----------------------------------------------
# File automatically generated during MySQL Router bootstrap
[DEFAULT]
user=root
logging_folder=/opt/mysqlrouter/log
runtime_folder=/opt/mysqlrouter/run
data_folder=/opt/mysqlrouter/data
keyring_path=/opt/mysqlrouter/data/keyring
master_key_path=/opt/mysqlrouter/mysqlrouter.key
connect_timeout=15
read_timeout=30
dynamic_state=/opt/mysqlrouter/data/state.json

[logger]
level = INFO

[metadata_cache:micCluster]
cluster_type=gr
router_id=1
user=mysql_router1_ux833ivpqki8
metadata_cluster=micCluster
ttl=0.5
use_gr_notifications=0

[routing:micCluster_rw]
bind_address=0.0.0.0
bind_port=6446
socket=/opt/mysqlrouter/mysql.sock
destinations=metadata-cache://micCluster/?role=PRIMARY
routing_strategy=first-available
protocol=classic

[routing:micCluster_ro]
bind_address=0.0.0.0
bind_port=6447
socket=/opt/mysqlrouter/mysqlro.sock
destinations=metadata-cache://micCluster/?role=SECONDARY
routing_strategy=round-robin-with-fallback
protocol=classic

[routing:micCluster_x_rw]
bind_address=0.0.0.0
bind_port=64460
socket=/opt/mysqlrouter/mysqlx.sock
destinations=metadata-cache://micCluster/?role=PRIMARY
routing_strategy=first-available
protocol=x

[routing:micCluster_x_ro]
bind_address=0.0.0.0
bind_port=64470
socket=/opt/mysqlrouter/mysqlxro.sock
destinations=metadata-cache://micCluster/?role=SECONDARY
routing_strategy=round-robin-with-fallback
protocol=x
-----------------------------------------------------
其中 user=mysql_router1_ux833ivpqki8 是在本机生成的访问集群的用户，密码是加密后存在keyring_path=/opt/mysqlrouter/data/keyring 和 master_key_path=/opt/mysqlrouter/mysqlrouter.key 位置中的。

修改 mysqlrouter 的服务启动文件，除了要移除用户 mysqlrouter 和用户组 mysqlrouter 外，还需要把命令启动配置文件的地址改为新的位置 /opt/mysqlrouter/mysqlrouter.conf
vi /usr/lib/systemd/system/mysqlrouter.service
--------------------------------------------------------------------------------------
[Unit]
Description=MySQL Router
After=syslog.target
After=network.target

[Service]
Type=simple
# User=mysqlrouter # 注意这里注释掉了
# Group=mysqlrouter # 注意这里注释掉了

PIDFile=/var/run/mysqlrouter/mysqlrouter.pid

ExecStart=/usr/bin/mysqlrouter -c /opt/mysqlrouter/mysqlrouter.conf # 这里是重点，需要修改为自动生成的配置文件位置

PrivateTmp=true

最后，在安装 mysql-router 的服务器上开启对应的端口，此外记得一定关闭 SELinux。
这里的端口号在自动生成的配置文件中解释的很清楚，6446 是外部程序访问 mysqlrouter 的时候使用传统 TCP 协议访问读写节点的端口地址，6447 是外部程序访问 mysqlrouter 的时候使用传统 TCP 协议访问只读节点的端口地址，这样用第三方组件，比如用 Sharding-JDBC 或者 MyCat 的时候就可以直接配置了
另外两个 64460 和 64470 是使用 MySQL 专有的 X 协议连接访问用的。用传统的就行。
firewall-cmd --permanent --zone=public --add-port=6446/tcp
firewall-cmd --permanent --zone=public --add-port=6447/tcp
firewall-cmd --permanent --zone=public --add-port=64460/tcp
firewall-cmd --permanent --zone=public --add-port=64470/tcp
firewall-cmd --reload

关闭 SELinux
setenforce 0
vi /etc/selinux/config
SELINUX=disabled

error-mysql InnoDB: Error:

error-mysql InnoDB: Error: "mysql"."innodb_table_stats

mysqlerror

附上错误日志：

2015-06-23 22:39:06 1252 [Note] Giving 0 client threads a chance to die gracefully
2015-06-23 22:39:06 1252 [Note] Shutting down slave threads
2015-06-23 22:39:06 1252 [Note] Forcefully disconnecting 0 remaining clients
2015-06-23 22:39:06 1252 [Note] Binlog end
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''partition''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''BLACKHOLE''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''PERFORMANCE_SCHEMA''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_DATAFILES''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_TABLESPACES''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_FOREIGN_COLS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_FOREIGN''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_FIELDS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_COLUMNS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_INDEXES''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_TABLESTATS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_SYS_TABLES''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_FT_INDEX_TABLE''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_FT_INDEX_CACHE''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_FT_CONFIG''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_FT_BEING_DELETED''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_FT_DELETED''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_FT_DEFAULT_STOPWORD''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_METRICS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_BUFFER_POOL_STATS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_BUFFER_PAGE_LRU''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_BUFFER_PAGE''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_CMP_PER_INDEX_RESET''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_CMP_PER_INDEX''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_CMPMEM_RESET''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_CMPMEM''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_CMP_RESET''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_CMP''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_LOCK_WAITS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_LOCKS''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''INNODB_TRX''
2015-06-23 22:39:09 1252 [Note] Shutting down plugin ''InnoDB''
2015-06-23 22:39:09 1252 [Note] InnoDB: FTS optimize thread exiting.
2015-06-23 22:39:09 1252 [Note] InnoDB: Starting shutdown...
2015-06-23 22:39:12 1252 [Note] InnoDB: Shutdown completed; log sequence number 44832642
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''ARCHIVE''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''MyISAM''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''CSV''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''MRG_MYISAM''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''MEMORY''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''sha256_password''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''mysql_old_password''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''mysql_native_password''
2015-06-23 22:39:12 1252 [Note] Shutting down plugin ''binlog''
2015-06-23 22:39:12 1252 [Note] /usr/sbin/mysqld: Shutdown complete

150623 22:39:12 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150623 22:39:39 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2015-06-23 22:39:39 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2015-06-23 22:39:39 1190 [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000)

2015-06-23 22:39:39 1190 [Warning] Buffered warning: Changed limits: table_cache: 431 (requested 2000)

2015-06-23 22:39:39 1190 [Note] Plugin ''FEDERATED'' is disabled.
2015-06-23 22:39:39 1190 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-06-23 22:39:39 1190 [Note] InnoDB: The InnoDB memory heap is disabled
2015-06-23 22:39:39 1190 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-06-23 22:39:39 1190 [Note] InnoDB: Memory barrier is not used
2015-06-23 22:39:39 1190 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-06-23 22:39:39 1190 [Note] InnoDB: Using Linux native AIO
2015-06-23 22:39:39 1190 [Note] InnoDB: Not using CPU crc32 instructions
2015-06-23 22:39:39 1190 [Note] InnoDB: Initializing buffer pool, size = 1.0G
2015-06-23 22:39:40 1190 [Note] InnoDB: Completed initialization of buffer pool
2015-06-23 22:39:40 1190 [Note] InnoDB: Highest supported file format is Barracuda.
2015-06-23 22:39:40 1190 [Note] InnoDB: 128 rollback segment(s) are active.
2015-06-23 22:39:40 1190 [Note] InnoDB: Waiting for purge to start
2015-06-23 22:39:40 1190 [Note] InnoDB: 5.6.22 started; log sequence number 44832642
2015-06-23 22:39:41 1190 [Note] Server hostname (bind-address): ''*''; port: 3306
2015-06-23 22:39:41 1190 [Note] IPv6 is available.
2015-06-23 22:39:41 1190 [Note] - ''::'' resolves to ''::'';
2015-06-23 22:39:41 1190 [Note] Server socket created on IP: ''::''.
2015-06-23 22:39:41 1190 [ERROR] Incorrect definition of table mysql.db: expected column ''User'' at position 2 to have type char(16), found type char(80).
2015-06-23 22:39:41 1190 [ERROR] Incorrect definition of table mysql.event: expected column ''definer'' at position 3 to have type char(77), found type char(141).
2015-06-23 22:39:41 1190 [ERROR] Incorrect definition of table mysql.event: expected column ''sql_mode'' at position 14 to have type set(''REAL_AS_FLOAT'',''PIPES_AS_CONCAT'',''ANSI_QUOTES'',''IGNORE_SPACE'',''NOT_USED'',''ONLY_FULL_GROUP_BY'',''NO_UNSIGNED_SUBTRACTION'',''NO_DIR_IN_CREATE'',''POSTGRESQL'',''ORACLE'',''MSSQL'',''DB2'',''MAXDB'',''NO_KEY_OPTIONS'',''NO_TABLE_OPTIONS'',''NO_FIELD_OPTIONS'',''MYSQL323'',''MYSQL40'',''ANSI'',''NO_AUTO_VALUE_ON_ZERO'',''NO_BACKSLASH_ESCAPES'',''STRICT_TRANS_TABLES'',''STRICT_ALL_TABLES'',''NO_ZERO_IN_DATE'',''NO_ZERO_DATE'',''INVALID_DATES'',''ERROR_FOR_DIVISION_BY_ZERO'',''TRADITIONAL'',''NO_AUTO_CREATE_USER'',''HIGH_NOT_PRECEDENCE'',''NO_ENGINE_SUBSTITUTION'',''PAD_CHAR_TO_FULL_LENGTH''), found type set(''REAL_AS_FLOAT'',''PIPES_AS_CONCAT'',''ANSI_QUOTES'',''IGNORE_SPACE'',''IGNORE_BAD_TABLE_OPTIONS'',''ONLY_FULL_GROUP_BY'',''NO_UNSIGNED_SUBTRACTION'',''NO_DIR_IN_CREATE'',''POSTGRESQL'',''ORACLE'',''MSSQL'',''DB2'',''MAXDB'',''NO_KEY_OPTIONS'',''NO_TABLE_OPTIONS'',''NO_FIELD_OPTIONS'',''MYSQL323'',''MYSQL40'',''ANSI'',''NO_AUTO_VALUE_ON_ZERO'',''NO_BACKSLASH_ESCAPES'',''STRICT_TRANS_TABLES'',''STRICT_A
2015-06-23 22:39:41 1190 [ERROR] Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
2015-06-23 22:39:41 1190 [Note] /usr/sbin/mysqld: ready for connections.
Version: ''5.6.22'' socket: ''/var/lib/mysql/mysql.sock'' port: 3306 MySQL Community Server (GPL)
2015-06-23 23:00:47 7f7038bc0700 InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch).
2015-06-23 23:00:47 7f7038bc0700 InnoDB: Error: Fetch of persistent statistics requested for table "moodle"."mdl_config" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

关于Mysql 显示 InnoDB 状态未在 Linux 上正确报告缓冲池统计信息的介绍已经告一段落，感谢您的耐心阅读，如果想了解更多关于1-2 【包子 mysql 系列】，对 mysql 的 innoDB 加锁分析、13.4 mysql 用户管理 13.5 常用 sql 语句 13.6 mysql 数据库备份恢复答疑：xtrabackup 备份 innodb 引擎的数据库、CentOS 8 安装 MySQL 8.0 InnoDB Cluster 集群以及 MySQL-Router 8、error-mysql InnoDB: Error: "mysql"."innodb_table_stats的相关信息，请在本站寻找。

本文标签：