问题概述
关于这个,博主是在迁移数据库的时候遇到的,
为了紧贴单位的发展战略及发展文化方针,给单位培养人才,先大胆的让同事先尝试着操作,最后出现问题了,博主就出场了,
查看事件内容提示:
“ 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:
文章来源:https://www.toymoban.com/news/detail-402462.html
好了,关于 Docker容器化部署报Fatal error: Can‘t open and lock privilege tables: Table ‘mysql.user‘ doesn‘t exis的解决办法 就写到这儿了,如果还有什么疑问或遇到什么问题欢迎扫码提问,也可以给我留言哦,我会一一详细的解答的。
歇后语:“ 共同学习,共同进步 ”,也希望大家多多关注CSND的IT社区。文章来源地址https://www.toymoban.com/news/detail-402462.html
作 者: | 华 仔 |
联系作者: | who.seek.me@java98k.vip |
来 源: | CSDN (Chinese Software Developer Network) |
原 文: | https://blog.csdn.net/Hello_World_QWP/article/details/124350450 |
版权声明: | 本文为博主原创文章,请在转载时务必注明博文出处! |
到了这里,关于Docker容器化部署报Fatal error: Can‘t open and lock privilege tables: Table ‘mysql.user‘ doesn‘t exis的解决办法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!