Docker容器化部署报Fatal error: Can‘t open and lock privilege tables: Table ‘mysql.user‘ doesn‘t exis的解决办法

问题概述

关于这个，博主是在迁移数据库的时候遇到的，

为了紧贴单位的发展战略及发展文化方针，给单位培养人才，先大胆的让同事先尝试着操作，最后出现问题了，博主就出场了，

查看事件内容提示：

“ Fatal error: Can‘t open and lock privilege tables: Table ‘mysql.user‘ doesn‘t exis ”

Debug的错误日志，如下图：

具体信息如下：

2022-04-22 14:18:09+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.51-1debian9 started.
2022-04-22 14:18:10+08:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2022-04-22 14:18:10+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.6.51-1debian9 started.
2022-04-22 14:18:10 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2022-04-22 14:18:10 0 [Note] mysqld (mysqld 5.6.51) starting as process 1 ...
2022-04-22 14:18:10 1 [Note] Plugin 'FEDERATED' is disabled.
mysqld: Table 'mysql.plugin' doesn't exist
2022-04-22 14:18:10 1 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
2022-04-22 14:18:10 1 [Note] InnoDB: Using atomics to ref count buffer pool pages
2022-04-22 14:18:10 1 [Note] InnoDB: The InnoDB memory heap is disabled
2022-04-22 14:18:10 1 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-04-22 14:18:10 1 [Note] InnoDB: Memory barrier is not used
2022-04-22 14:18:10 1 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-04-22 14:18:10 1 [Note] InnoDB: Using Linux native AIO
2022-04-22 14:18:10 1 [Note] InnoDB: Using CPU crc32 instructions
2022-04-22 14:18:10 1 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2022-04-22 14:18:10 1 [Note] InnoDB: Completed initialization of buffer pool
2022-04-22 14:18:10 1 [Note] InnoDB: Highest supported file format is Barracuda.
2022-04-22 14:18:10 1 [Note] InnoDB: Log scan progressed past the checkpoint lsn 49463
2022-04-22 14:18:10 1 [Note] InnoDB: Database was not shutdown normally!
2022-04-22 14:18:10 1 [Note] InnoDB: Starting crash recovery.
2022-04-22 14:18:10 1 [Note] InnoDB: Reading tablespace information from the .ibd files...
2022-04-22 14:18:10 1 [Note] InnoDB: Restoring possible half-written data pages
2022-04-22 14:18:10 1 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1600607
2022-04-22 14:18:10 1 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2022-04-22 14:18:11 1 [Note] InnoDB: 128 rollback segment(s) are active.
2022-04-22 14:18:11 1 [Note] InnoDB: Waiting for purge to start
2022-04-22 14:18:11 1 [Note] InnoDB: 5.6.51 started; log sequence number 1600607
2022-04-22 14:18:11 1 [Note] RSA private key file not found: /var/lib/mysql//private_key.pem. Some authentication plugins will not work.
2022-04-22 14:18:11 1 [Note] RSA public key file not found: /var/lib/mysql//public_key.pem. Some authentication plugins will not work.
2022-04-22 14:18:11 1 [Note] Server hostname (bind-address): '*'; port: 3306
2022-04-22 14:18:11 1 [Note] IPv6 is available.
2022-04-22 14:18:11 1 [Note]   - '::' resolves to '::';
2022-04-22 14:18:11 1 [Note] Server socket created on IP: '::'.
2022-04-22 14:18:11 1 [Warning] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2022-04-22 14:18:11 1 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist

解决办法

问题原因：

经过系统排查，文件对比，发现是因为缺少MySQL数据库的系统文件 “ performance_schema ”

同事在备份的时候，只关注到数据库文件的迁移，而缺少performance_schema

第一种解决方案：

（注意：在迁移/备份数据库前，一定要停止MySQL服务，一定要！！！不论是源服务，还是目标服务）

出现 “ Fatal error: Can‘t open and lock privilege tables: Table ‘mysql.user‘ doesn‘t exis ”

的文件内容如下，处理前的目录：

把数据库文件 “ performance_schema ” 复制到MySQL的/data文件夹后，如下图：

再次拉MySQL容器服务，就可以成功启动了，如下图：

第二种解决方案：

（这个方案适合MySQL Server直接部署到宿主机上的）

1、清空MySQL /data 目录下的所有文件；

2、重新初始化MySQL数据库，输入指令，

“ mysqld --initialize --user=root --basedir=/home --datadir=/var/lib/mysql ”

3、将备份的数据库重新考入到/data目录下，解压，启动即可，

（注意在迁移备份数据库之前，千万！千万！千万要停止MySQL服务，否则，后面一定会出问题，而且出了问题还不好排查的）

补充知识：

performance_schema & information_schema：

information_schema 数据库跟 performance_schema 相同，都是 MySQL 自带的信息数据库。其中 performance_schema 主要作用于性能分析，而 information_schema 主要作用于存储MySQL数据库的元数据（数据的数据），例如：新增的数据库属性、表属性、列的数据类型、访问权限等属性数据。

performance_schema是一种用于MySQL底层监视服务执行情况的，关于performance_schema的一些作用如下：

在数据库启动/运行时实时检查记录MySQL Server的内部执行情况。performance_schema 数据库中的表使用performance_schema存储引擎。该数据库主要用于存储整个MySQL数据库运行过程中的性能数据采集存储，与information_schema不同，information_schema主要关注MySQL Server运行过程中的元数据信息；
performance_schema通过监视MySQL Server的事件来实现监视服务内部运行情况， “事件”就是MySQL 服务内部活动中所做的任何事情以及对应的时间消耗，利用这些信息来判断MySQL的资源消耗性能瓶颈的所在，一般来说，事件可以是函数调用、操作系统的等待、SQL语句执行的阶段或者整个SQL语句与SQL语句集合。事件的采集可以方便的提供MySQL Server中的相关存储引擎对磁盘文件、表I/O、表锁等资源的调用等信息；
performance_schema中的事件只记录在本地MySQL Server的performance_schema中，但是在performance_schema数据库下表中数据发生变化时不会被写入binlog中（这个是需要注意的点），也不会通过复制机制被复制到其他MySQL服务中；
记录当前表中活跃事件、历史事件和事件摘要相关的信息。例如：提供表的某个事件的执行次数、消耗时长，进而可用于分析某个特定线程、特定对象相关联的活动；
performance_schema中的事件与写入二进制日志中的事件（数据修改的events）、计划事件调度程序（一种存储程序）的事件不同，performance_schema中的事件记录的是执行某些活动对某些资源的消耗，例如：执行的时长、执行的次数等信息；
performance_schema存储引擎使用MySQL Server 源代码中的“检测点”来实现事件数据的收集，performance_schema实现机制本身的代码没有相关的单独线程来检测，这与其他功能有所不同，例如：复制事件、事件计划程序；
所有收集的事件信息存储在performance_schema数据库表中。这些表可以使用SELECT语句查询，也可以使用SQL语句更新performance_schema数据库中表的记录，注意：performance_schema中表的修改会立即生效，影响数据采集；
performance_schema中的表的数据不会持久化存储在磁盘中，而是保存在“内存”中，一旦服务器重启，这些数据会丢失的风险，包括系统表在内的整个performance_schema下所有的数据；
只要是受MySQL Server支持平台，都可以实现事件监控，但是可能会存在事件消耗计数器统计类型不一的情况；

information_schema 数据库中经常用到的数据表：

表名	描述
SCHEMATA	提供了关于数据库的信息；
TABLES	提供了关于数据库中的表的信息；
COLUMNS	提供了表中的列信息；
STATISTICS	提供了关于表索引的信息；
USER_PRIVILEGES	提供了关于全程权限的信息，该信息源自mysql.user授权表；
SCHEMA_PRIVILEGES	提供了关于方案（数据库）权限的信息。该信息来自mysql.db授权表；
TABLE_PRIVILEGES	提供了关于表权限的信息。该信息源自mysql.tables_priv授权表；
COLUMN_PRIVILEGES	提供了关于列权限的信息。该信息源自mysql.columns_priv授权表；
TABLE_CONSTRAINTS	描述了存在约束的表；
KEY_COLUMN_USAGE	描述了具有约束的键列；
ROUTINES	提供了关于存储子程序（存储程序和函数）的信息。此时，ROUTINES表不包含自定义函数（UDF）；
VIEWS	提供了关于数据库中的视图的信息；
TRIGGERS	提供了关于触发程序的信息；
CHARACTER_SETS	提供了关于可用字符集的信息；
COLLATIONS	提供了关于各字符集的对照信息；

关于information_schema数据库中字段“ TABLE_CATALOG ”：
MySQL系统的information_schema数据库中，很多表都存在TABLE_CATALOG字段，MYSQL官方文档中说，这个字段值永远是def，但没写明这个字段是作用什么的。博主在网上搜罗了一下，很多把这个叫表的“限定符”，感觉好像是和其它关系型数据库作区分用的（Oracle、MySQL、Microsoft SQL Server、Microsoft Access等）。如下3连图ss222：

好了，关于 Docker容器化部署报Fatal error: Can‘t open and lock privilege tables: Table ‘mysql.user‘ doesn‘t exis的解决办法就写到这儿了，如果还有什么疑问或遇到什么问题欢迎扫码提问，也可以给我留言哦，我会一一详细的解答的。
歇后语：“ 共同学习，共同进步 ”，也希望大家多多关注CSND的IT社区。

作者：	华仔
联系作者：	[email protected]
来源：	CSDN (Chinese Software Developer Network)
原文：	https://blog.csdn.net/Hello_World_QWP/article/details/124350450
版权声明：	本文为博主原创文章，请在转载时务必注明博文出处！