在 Linux 上自建 MySQL 服务器，经常遇到各种无法启动或启动后异常的问题，本文列举一些常见问题的解决办法。
最近一个安装宝塔环境的项目，mysql老是关闭停止了。连续好多次了，然后我就发现不对劲。然后去查了下日志，日志内容：
作者介绍：谢浩，现任职于云和恩墨（北京）信息技术有限公司，具有多年oracle数据库企业级运维经验，擅长结合业务、硬件系统制定各种项目方案，具有丰富mysql相关的工作经验。 假设你在使用MySQL中的InnoDB驱动，由于遇到了驱动程序错误，内核错误，电源故障或某些罕见的MySQL错误，而在InnoDB ibdata1文件损坏，实例不能启动。你该怎么办呢？ 案例描述 某门户mysql innodb数据库实例损坏，数据库服务无法启动，使用文件系统上的数据库frm及bid文件恢复数据库内的业务数据。 相关知识
前几天在部署k3s相关服务时，不小心把操作系统整坏了。导致无法启动，磁盘上还有我的一些重要数据。
3）启动mysqld进程后，如果没有在my.cnf文件里增加该参数，启动时会报错，报错日志如下：
至少有两种方法可用： 方法一，查询MySQL日志。 如果MySQL实例自从初始化后的日志一直留存着的话，自然可以查到当时的时间。
本文主要是介绍如何在Windows64位MySQL配置式安装，一定要一步一步按步骤进行，本人也是根据个人踩过的坑总结的
Forcing InnoDB Recovery提供了6个等级的修复模式，需要注意的是值大于3的时候，会对数据文件造成永久的破坏，不可恢复。六个等级的介绍摘抄如下：
操作系统：CentOS 7 Mysql版本：Mysql 8.0.x Docker版本：Docker version 20.10.10
爱可生 DBA 成员，一个执着于技术的数据库工程师，主要负责数据库日常运维工作。擅长 MySQL，Redis 及其他常见数据库也有涉猎；喜欢垂钓，看书，看风景，结交新朋友。
DDL 相对于数据库的 DML 之类的其他操作，相对来说是比较耗时、相对重型的操作; 因此对业务的影比较严重。MySQL 从5.6版本开始一直在持续改进其DDL性能：引入了 online DDL，inplace DDL，instant DDL 等实用性极强的功能， DDL 目前对业务的影响持续降低。
RAID5磁盘阵列，由于未知的原因导致存储忽然崩溃无法启动，RAID5阵列中的虚拟机全部丢失，其中3台虚拟机为重要数据，需要主要针对该3台虚拟机进行数据恢复。
本文为joshua317原创文章,转载请注明：转载自joshua317博客 https://www.joshua317.com/article/289
专注于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。现在鼎甲科技任顾问，为同事和客户提供数据库培训和技术支持服务。
从日志中可以看出是innodb引擎出了问题。日志里提示到 http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html查看强制恢复的方法。
本次分享的案例是关于存储的数据恢复，存储上RAID崩溃导致存储无法启动。存储内部共有6台以上虚拟机，其中LINUX虚拟机3台为客户重要数据。 工程师初步分析得出存储结构为所有物理磁盘均在一个存储池内，再由存储池分出几个LUN，LUN1是vmfs卷，三台LINUX虚拟机也是在这个里面。 1、重组RAID 重组过程中发现本RAID5缺失2块盘（第一掉线盘掉线后热备盘顶替，之后又掉线一块盘使得RAID5处于降级状态。最后在掉线第三块盘时盘片划伤RAID崩溃），无法通过校验直接获取丢失盘的数据，所以只能使用磁盘同等大小的全0镜像进行重组（此方法只可用于紧急情况，因为依赖空镜像组成的RAID文件系统结构会被严重破坏，相当于每个条带都会缺失两个块的数据）。 2、提取LUN 分析存储结构，获取存储划分的MAP块。在找到MAP块之后解析得到各个LUN的数据块指针，编写数据提取程序提取LUN碎片。提取完成后进行碎片拼接，组成完整LUN。导出LUN内所有虚拟机，尝试启动。导出虚拟机后尝试启动，同预想相同，操作系统被破坏虚拟机无法启动。 3、提取虚拟机内文件 在虚拟机无法启动的情况下只能退而求其次，提取虚拟机内文件。在取出文件后进行测试，发现大多数文件都被破坏，只有少部分小文件可以打开。在与客户沟通后得知虚拟机内有MYSQL数据库，因为数据库底层存储的特殊性，可以通过扫描数据页进行数据提取。在找到此虚拟机后发现虚拟机启用快照，父盘和快照文件都被损坏的情况下常规合并操作无法完成，使用北亚自主研发VMFS快照合并程序进行快照合并。 4、获取MYSQL数据页并分析 根据MYSQL数据页特征进行数据页扫描并导出（innodb引擎可以使用此方案，myisam因为没有“数据页”概念所以不可用），分析系统表获取各用户表信息，根据各个表的ID进行数据页分割。 5、提取表结构 因为数据库使用时间已久，表结构也曾多次变更，加上系统表在存储损坏后也有部分数据丢失，记录提取过程遇到很大阻力。首先获取最初版本数据库各个表的表结构：合并快照前的父盘因为写入较早，使用第一块掉线盘进行校验获取到这个文件的完整数据，然后提取出其中数据库各个表的表结构，之后客户方提供了最新版的数据库建表脚本。提取记录：分别使用两组不同表结构对数据记录进行提取并导入恢复环境中的MYSQL数据库内，然后剔除各个表中因为表结构变更造成的乱码数据，最后将两组数据分别导出为.sql文件。 6、数据恢复结果 因为两个版本的数据库表结构不同，所以联系了客户方的应用工程师进行调试。调试完成后导入平台，经验证，数据可用本次数据恢复成功。
更新了mysqld之后发现无法启动了，查看了日志tail -n 20 /var/log/mysqld.log后发现有如下字眼：
摘录自：http://gfsunny.blog.51cto.com/990565/1566683
专注于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。现在鼎甲科技任技术顾问，为同事和客户提供数据库培训和技术支持服务。
某公司使用的存储，采用RAID5磁盘阵列，由于未知的原因导致存储忽然崩溃无法启动，RAID5阵列中的虚拟机全部丢失，其中3台虚拟机为重要数据，需要主要针对该3台虚拟机进行数据恢复。
彻底放弃了Windows11 昨晚格盘重装Windows10，秉承着本地环境可以不用，但是不能没有的原则还是装了一下用过很久很久的PHPenv
在InnoDB中我们可能会遇到死锁，一般情况下我们对于死锁无需关注，MySQL会自己处理，不过如果我们在error日志中发现大量的死锁，就需要我们检查应用并进行相应的处理
一、数据库信息： 数据库版本：5.7.21-log 某银行测试数据库，APP业务库内有一个含有大量（几百个）分区表的大表test_app。DROP该分区表的大表后导致无法重建该分区表。 二、问题描述： 客户使用“drop table test_app;”时，显示表删除成功。当重新执行该表的建表语句时，报错“Table 'app.test_app /* Partition p0 */' already exists” 三、问题分析： 3.1> 原因是GreatSQL 5.7数据库DDL没有原子性，drop表的删除动作没有执行完成； 3.2> 进入数据库“show tables”查看test_app表已不存在； 3.3> 进入数据库所在的目录下，查看test_app表的相关文件。test_app.frm文件已不存在，但是有大量的"test_app#P***.ibd"分区表文件存在。关闭数据库，移除这些分区表文件到其他目录，启动数据库；数据库无法启动，报“无法找到这些分区表文件”的错误； 3.4> 重新创建test_app表时，报“table already exists”错。 3.5> 感觉进入了死胡同，最先想到的直截了当方法是备份APP业务库内除这张表的其他表，删除该数据库后，进行APP业务数据库的恢复，该方法没有测试，觉得太麻烦。 四、问题处理（方法一，测试步骤）： 4.1> 新建一个临时库test，依据app库目录里的数据文件名称，修改建表语句后，执行test_app表的建表SQL语句，生成test_app.frm文件； 4.2> 关闭数据库，修改数据库配置文件my.cnf文件的参数为“innodb_file_per_table=OFF”； 4.3> 把临时库test目录下的test_app.frm文件拷贝到业务数据库app目录下，启动数据库； 4.4> 进入业务数据库APP，可以看到test_app表； 4.5> 执行“drop table test_app;”语句，成功删除了表。关闭数据库； 4.6> 进入业务数据库app对应的目录下，test_app.frm文件已不存在，但是有个test_app#P***.ibd分区表文件存在。手工删除该ibd文件。 4.7>修改数据库配置文件my.cnf文件的参数为“innodb_file_per_table=ON”;启动数据库。 4.8> 重新执行test_app表的建表SQL语句。即可成功创建表。 五、问题处理（方法二，客户执行步骤）： 5.1> 设置innodb_file_per_table=OFF：set global innodb_file_per_table='OFF'; 5.2> 执行test_app表的建表语句，建表成功。 5.3> 删除test_app表drop table test_app； 5.4> 重启数据库。 5.5> 再执行test_app表的建表语句，建表成功。
机房一台服务器上的mysql运行一段时间了，突然出现了一个很奇怪的现象：重启后无法恢复了！准确情况是：启动mysql后随即就又关闭了。 查看mysql错误日志如下： 160920 22:41:41 mysqld_safe Starting mysqld daemon with databases from /home/MysqlData/ 2016-09-20 22:41:41 0 [Note] /Data/app/mysql5.6.25/bin/mysqld (mysqld 5.6.25-log) sta
MySQL主从复制(Master-Slave)也叫AB复制，Mysql作为目前世界上使用最广泛的免费数据库，相信所有从事系统运维的工程师都一定接触过。但在实际的生产环境中，由单台Mysql作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。因此，一般来说都是通过主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力这样的方案来进行部署与实施的。
mysql8 是早早晚晚都的上的版本，早上会让开发欣喜，因为很多不支持的功能都开始支持，而尤其是MGR 方面的完善和物理复制的插件等等也是D们期待的。晚上也是有道理的，查询的速度估计会让继续使用MYSQL.5.7的感到欣慰。
今天有个网友问我一个MySQL的恢复问题。提供的截图如下。 对于这个问题，在一些断电的场景下还是可能出现的。我首先是要确认是否为线上业务还是测试环境，线上业务来说这个影响还是很大的。如果数据库
本文介绍GreatSQL的一些关键新特性，相关特性主要针对GreatSQL 8.0.x版本（不含GreatSQL 5.7.x版本中的相关特性）。
你知道MySQL启停都做了些什么吗？ 启动的时候初始化配置文件，读取redo配合binlog进行事务recover；停止的时候好像没有啥操作可做；印象中除了这些，就再没有了，至少在今天之前，我是这么认为的，我是真的肤浅。 今天就来聊一聊MySQL关于启停的常规操作。
最近整理了一下MySQL 8.0的自动化安装，其中用到了一个MySQL 5.7版本的自定义配置文件，由于没有对（MySQL 8.0）做针对性修改，导致安装过程中出现了一些错误 其中部分原因就是MySQL 5.7时代的配置在MySQL 8.0不再被支持，同时某些参数不再建议使用，如果继续保留在配置文件中，会导致8.0实例无法启动。
你知道MySQL启停都做了些什么吗？启动的时候初始化配置文件，读取redo配合binlog进行事务recover，停止的时候好像没有啥操作可做；印象中除了这些，就再没有了，至少在今天之前，我是这么认为的，我是真的肤浅。今天就来聊一聊MySQL关于启停的常规操作。
有的lnmp环境包或yum安装方式默认将mariadb数据库装在系统盘，其中就包括数据存储文件，万一系统宕机无法启动，那么数据文件就有损坏的可能，甚至造成无法挽回的局面。接下来我们就可以单独将数据存储文件放在其他分区或数据盘，这样即便是系统挂掉，也能轻易快速恢复mariadb数据库的正常运行。
摘要:从MySQL 5.7开始没有data文件夹，如果不进行初始化的话，mysql服务是无法启动的 正文: MySQL的安装 去官网下载zip格式的Mysql Server的压缩包（绿色版），根据个人电脑选择x86或者x64版本，点击最下面的跳过登录下载。 解压，复制my-dafault.ini到bin目录下，重命名为my.ini。可以根据需要复制以下内容： 12345678910111213141516[mysql]# 设置mysql客户端默认字符集default-character-set=utf8
之前安装mysql时未做总结，换新电脑，补上安装记录，安装的时候，找了些网友的安装记录，发现好多坑 1、mysql-5.7.12-winx64.zip下载 官方下载地址:http://dev.mysql.com/downloads/mysql/ 2.解压到C:\job\mysql-5.7.12-winx64 3.在C:\job\mysql-5.7.12-winx64下新建my.ini配置文件 内容如下： ####################配置文件开始################### # Fo
作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：
◆ 概述 最近公司做了一个关于SQLSERVER的大项目，所以对SQL SERVER进行了探究。master数据库，是SQL Server中最重要的系统数据库。master数据库包含有关 SQL Server 系统的所有信息，包括有关初始化的信息、配置设置、与实例相关的元数据、有关所有其他数据库的信息，例如数据库文件的位置等。这就是为什么主数据库的存在和正常功能对于任何 SQL Server 实例都是至关重要的。在本文中，我们将说明有关这个重要数据库的五个事实。 ◆ 解决方案 通过以下几个事实，我们将阐明m
数据库“断页”是个很有意思的话题，目前任何数据库应该都绕不过去。我们知道数据库的块大小一般是8k、16k、32k，而操作系统块大小是4k，那么在数据库刷内存中的数据页到磁盘上的时候，就有可能中途遭遇类似操作系统异常断电而导致数据页部分写的情况，进而造成数据块损坏，数据块损坏对于某些数据库是致命的，可能导致数据库无法启动。既然对于断页问题数据库都可能遇到，那么再来看看主流数据库是如何避免发生断页的。
1. 在MySQL官网 http://dev.mysql.com/downloads/mysql/ 上面下载ZIP安装包(第二个:Windows (x86, 64-
GreatSQL是由万里数据库维护的MySQL分支，开源、免费。GreatSQL基于Percona Server，在其基础上进一步提升MGR（MySQL Group Replication）的性能及可靠性。此外，GreatSQL合并了华为鲲鹏计算团队贡献的Patch，实现了InnoDB并行查询特性，以及对InnoDB事务锁的优化。
Windows 安装 MySQL5.7.17 在MySQL官网 http://dev.mysql.com/downloads/mysql/ 上面下载ZIP安装包（第二个：Windows (x86, 64-bit), ZIP Archive）。 下载完成后解压，将其放到想要安装的目录下。 例如：D:\MySQL5.7\mysql-5.7.17-winx64 新建一个my.ini配置文件，原始的my-default.ini配置文件只是个模版，不要在里面改动。 my.ini的内容如下： ``` [mysql] d
作为linux运维，多多少少会碰见这样那样的问题或故障，从中总结经验，查找问题，汇总并分析故障的原因，这是一个Linux运维工程师良好的习惯。每一次技术的突破，都经历着苦闷，伴随着快乐，可我们还是执着的继续努力，从中也积累了更多的经验，这就是实践给予我们的丰厚回报。 下面汇总了我做项目过程可能出现的故障及解决方法，看看是否与你有共鸣，并对你有帮助？ ---- 第一：常见问题解决集锦 1.shell脚本不执行 问题：某天研发某同事找我说帮他看看他写的shell脚本，死活不执行，报错。我看了下，
作为运维，多多少少会碰见这样那样的问题或故障，从中总结经验，查找问题，汇总并分析故障的原因，这是一个运维工程师良好的习惯。每一次技术的突破，都经历着苦闷，伴随着快乐，可我们还是执着的继续努力，从中也积累了更多的经验，这就是实践给予我们的丰厚回报。
在本博客中，我们将和大家讨论下 MySQL 数据库安装后，建议调整的十个性能设置参数。
说起来日常的故障，其实，首先应该相到的就是：“备份”、“备份”、“备份”。毕竟再怎么牢固的系统或硬件都会有故障的时候，所以，备份放第一位。
1. 官网下载并解压 我下载的是mysql-8.0.11-winx64 下载地址:https://dev.mysql.com/downloads/file/?id=476233 2. 设置系统环境变量
墨墨导读：日常MySQL运维中，会遇到各种各样的问题，下面分享二十个MySQL运维案例，附有问题的分析和解决办法，希望你遇到同样的问题的时候，可以淡定地处理。
作者简介：姚远，MySQL ACE，华为云 MVP ，专注于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。现在鼎甲科技任技术顾问，为同事和客户提供数据库培训和技术支持服务。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
