官答|初始化GreatSQL报错无法找到数据目录或初始化数据字典失败
官答|初始化GreatSQL报错无法找到数据目录或初始化数据字典失败
GreatSQL推出新栏目——官答
官答栏目针对GreatSQL数据库中的问题,选取官方论坛和讨论群中的典型提问进行深入解答。内容涵盖数据库安装部署、配置优化、故障排查、性能测试等方面。
在文章中,我们不仅提供解决方案,还会结合实例深入剖析问题的成因,提升读者对GreatSQL数据库的理解能力。
如果你在管理、使用GreatSQL数据库时遇到棘手的技术难题,想系统地学习提高数据库技能,就来看看官答的文章吧。这里不仅可以找到可靠的解决方法,还能从中学习到数据库优化的经验和思路。
通过阅读官答的内容,可以全面地掌握GreatSQL数据库管理的技能,熟练应对各种故障情况。快来关注官答栏目,与我们一起成长!
本问题也是来自讨论群,用户使用的是GreatSQL-8.0.32-24版本数据库
- GreatSQL-8.0.32-24-Linux-glibc2.28-x86_64-minimal.tar.xz
GreatSQL是一款开源免费数据库,可在普通硬件上满足金融级应用场景,具有高可用、高性能、高兼容、高安全等特性,可作为MySQL或Percona Server for MySQL的理想可选替换。
用户提供错误日志如下
$ cat error.log 2023-10-27T11:18:22.862989+08:00 0 [Warning] [MY-011069] [Server] The syntax '--slave-rows-search-algorithms' is deprecated and will be removed in a future release. 2023-10-27T11:18:22.863011+08:00 0 [Warning] [MY-011069] [Server] The syntax '--master-info-repository' is deprecated and will be removed in a future release. 2023-10-27T11:18:22.863025+08:00 0 [Warning] [MY-011069] [Server] The syntax '--relay-log-info-repository' is deprecated and will be removed in a future release. 2023-10-27T11:18:22.864851+08:00 0 [Warning] [MY-010101] [Server] Insecure configuration for --secure-file-priv: Location is accessible to all OS users. Consider choosing a different directory. 2023-10-27T11:18:22.864949+08:00 0 [Note] [MY-010949] [Server] Basedir set to /usr/local/greatsql/. 2023-10-27T11:18:22.864966+08:00 0 [System] [MY-010116] [Server] /usr/local/greatsql/bin/mysqld (mysqld 8.0.25) starting as process 94635 2023-10-27T11:18:22.876808+08:00 0 [Note] [MY-012366] [InnoDB] Using Linux native AIO 2023-10-27T11:18:22.877183+08:00 0 [Note] [MY-010747] [Server] Plugin 'FEDERATED' is disabled. 2023-10-27T11:18:22.880103+08:00 1 [ERROR] [MY-011011] [Server] Failed to find valid data directory. 2023-10-27T11:18:22.880512+08:00 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed. 2023-10-27T11:18:22.880639+08:00 0 [ERROR] [MY-010119] [Server] Aborting 2023-10-27T11:18:22.880688+08:00 0 [Note] [MY-010120] [Server] Binlog end 2023-10-27T11:18:22.880931+08:00 0 [Note] [MY-010733] [Server] Shutting down plugin 'MyISAM' 2023-10-27T11:18:22.880972+08:00 0 [Note] [MY-010733] [Server] Shutting down plugin 'InnoDB' 2023-10-27T11:18:22.881011+08:00 0 [Note] [MY-010733] [Server] Shutting down plugin 'CSV' 2023-10-27T11:18:22.881047+08:00 0 [Note] [MY-010733] [Server] Shutting down plugin 'daemon_keyring_proxy_plugin' 2023-10-27T11:18:22.881569+08:00 0 [System] [MY-010910] [Server] /usr/local/greatsql/bin/mysqld: Shutdown complete (mysqld 8.0.25) MySQL Community Server -
用户采用初始化命令如下
$ /usr/local/greatsql/bin/mysqld --defaults-file=/etc/my.cnf -initialize --user=mysql --datadir /data/greatsql --lower-case-table-names=1
其实在这里就可以看出问题所在 :)
尝试解决
我们可以从以下几个方面进行检查,排查数据目录失效的原因:
- 检验数据目录
/data/greatsql
是否真实存在。 - 检查
/data/greatsql
目录的权限设置是否正确,避免因权限问题导致无法访问。 - 在my.cnf配置文件中核对datadir参数是否设置正确,不存在误指向其他目录的情况。
- 查看操作系统的存储空间是否充足。
经过仔细的排查验证,确认这些配置都是正确的,数据目录存在并且具有可访问权限,my.cnf中的参数也没有错误。
集思广益
针对此问题,群友们积极提出了解决思路:
- 首先,有用户建议去掉执行sql语句末尾的
"--lower-case-table-names=1"
参数,并尝试执行。但遗憾的是,删除该参数后问题仍然存在,没有得到解决。 - 其次,另一位用户分析可能是my.cnf配置文件的默认参数干扰了sql语句,因此建议暂时改变my.cnf的文件名或注释默认调用配置,再执行sql,看看是否能避开默认参数的影响。但是该建议未得到验证,预计执行结果也是相同的错误。
群友们提出的方法尚未奏效,那这件事情就很奇怪,到底是哪里出现了问题呢?
问题解决
其实我们再回头来看看初始化命令
$ /usr/local/greatsql/bin/mysqld --defaults-file=/etc/my.cnf -initialize --user=mysql --datadir /data/greatsql --lower-case-table-names=1
接着我们再来看看GreatSQL官方文档是怎么初始化的
※ 截取自GreatSQL官方手册 【Ubuntu系统中安装GreatSQL】➥https://gitee.com/GreatSQL/GreatSQL-Manual/blob/master/4-install-guide/3-2-ubuntu-install.md
$ mysqld --defaults-file=/etc/mysql/my.cnf --initialize-insecure --user=mysql
眼尖的同学已注意到执行语句出现格式错误,initialize
前缺少一个连接符"-"
,此处用户是复制粘贴它处的命令进行使用,在操作过程中不小心遗漏了一个字符,导致语法格式不正确,执行失败。
及时发现并添加上这个简单的连接符后,问题迎刃而解,语句成功执行。
可以看出,大多数问题的起因都是我们在操作过程中的一时疏忽或不留神造成的。正如这句话说得好:“大部分问题,都是粗心大意导致的”。
这个案例也提醒我们,在数据库开发和管理中,任何一个细节都不可忽视。应保持高度的专注和细致,检查每个步骤的语法和逻辑,以减少人为操作失误出现的可能。
这里建议大家采用GreatSQL提供的官方手册文档,按照流程进行安装部署。
GreatSQL手册都是经过详细验证的,每个步骤都经历了测试,确保可靠性。遵循手册的安装方法,能够帮助用户顺利完成环境配置,避免踩坑。
我们GreatSQL提供了多种灵活的安装方式,可满足不同需求:
-
RPM方式提供了便捷的包管理安装。
-
二进制安装方式具有极强的跨平台兼容性,支持CentOS、Ubuntu、OpenEuler、统信UOS、龙蜥、麒麟等主流操作系统。
-
源码编译方式可以全面自定义编译参数,适用于对性能和定制化要求极高的场景。
-
Ansible安装自动化程度高,可以轻松实现大规模集群部署,以及Docker方式安装GreatSQL数据。
通过这些安装方式,GreatSQL可以应对各种复杂的生产环境,无论是传统的物理机部署,还是新的虚拟化和容器化部署,手册都能助您快速上手,节省宝贵时间。
GreatSQL安装手册➥https://gitee.com/GreatSQL/GreatSQL-Manual/blob/master/4-install-guide/0-install-guide.md
常规解决
这个错误通常是由于GreatSQL无法找到有效的数据目录导致的。可能的原因是在安装GreatSQL时指定了不正确的数据目录或者数据目录不可用,常规的解决方法就是:
1.确认GreatSQL目录是否存在
2.检查GreatSQL目录权限是否正常,通常确保是MySQL用户有该目录的权限
3.确保GreatSQL目录为空,因为初始化失败可能导致目录中还有数据,如果重新初始化要确保目录为空
4.如果GreatSQL目录不存在,可以尝试手动创建数据目录
5.如果GreatSQL目录存在但是不可用,可以尝试在指定另一个数据目录或重新安装GreatSQL
如果以上方法都无法解决,那快到GreatSQL官网发个帖子吧➥https://greatsql.cn/forum-36-1.html
Enjoy GreatSQL :)
关于 GreatSQL
GreatSQL是适用于金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。
相关链接: GreatSQL社区 Gitee GitHub Bilibili
GreatSQL社区:
社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html
社区博客有奖征稿详情: https://greatsql.cn/thread-100-1-1.html
(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)
技术交流群:
微信&QQ群:
QQ群:533341697
微信群:添加GreatSQL社区助手(微信号:wanlidbc
)好友,待社区助手拉您进群。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
深度实践 | 自如基于Apache StreamPark 的实时计算平台实践
导读:自如作为一家专注于提供租房产品和服务的 O2O 互联网公司,构建了一个涵盖城市居住生活领域全链条的在线化、数据化、智能化平台,实时计算在自如一直扮演着重要的角色。到目前为止,自如每日需要处理 TB 级别的数据,本文由自如的实时计算小伙伴带来,介绍了自如基于 StreamPark 的实时计算平台深度实践。 实时计算遇到的挑战 需求解决方案之路 基于StreamPark 的深度实践 实践经验总结和示例 带来的收益 未来规划 自如作为提供租房产品及服务的 O2O 互联网品牌,成立于 2011 年 10 月,自如已为近 50 万业主、500 万自如客提供服务,管理房源超过 100 万间。自如通过打造涵盖 To C 和 To B 的品质居住产品、逐步实现城市居住生活领域全链条的线上化、数据化、智能化的平台能力。自如 APP 装机量累计达 1.4 亿次,日均线上服务调用达 4 亿次,拥有智能化房源万余间。自如现已在 PC、APP、微信全渠道实现租房、服务、社区的 O2O 闭环,省去传统租房模式所有中间冗余环节,通过 O2O 模式重构居住市场格局,并建立了中国最大的 O2O 青年居住社区。 ...
- 下一篇
八怪:再谈 MySQL 8 这两个精准的时间戳
MySQL 8.0 的 binlog 中多了 immediate_commit_timestamp 和 original_commit_timestamp 的信息,网上也有很多文章进行解释,最近也刚好遇到相关问题,刚好稍微学习一下。 作者:高鹏(八怪),《MySQL 主从原理》作者,深入透彻理解 MySQL 主从,GTID 相关技术知识。 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 本文共约 1700 字,预计阅读需要 6 分钟。 相关解释 **immediate_commit_timestamp:**代表是当前数据库提交的时间,从库/主库都分别代表其提交的时间。 **original_commit_timestamp:**代表主库提交的时间,不管有多少级联的从库这个时间永远是主库提交事务时候的时间。当然在主库上其就等于 immediate_commit_timestamp 的时间。 它们的生成时间都是在从 binlog cache 写入到 binlog 文件的时候,生成 GTID event 的时候,也就是 commit 的 flush 阶段,我们简...
相关文章
文章评论
共有0条评论来说两句吧...