我的 WAMP 目录不小心被另一个用户删除了。MySQL 中只有数据文件夹可用。并且，只有数据库文件夹（“\bin\mysql\mysql5.6.12\data\”中带有数据库名称的文件夹）可用。“\bin\mysql\mysql5.6.12\data\”根目录下包括“ ibdata1 ”在内的所有文件也被删除。
数据库文件夹仅包含以下扩展名的文件。
*.frm，*.ibd
和“db.opt”文件。
如何恢复数据库？
我已经尝试恢复 bdata1。但是，无法收回。而且，一些数据库也包含 MYISAM。
我设置了 innodb_file_per_table 并且就在今天，在我对 800M 表进行了几次更改以将其减少到大约 600M 之后，我的 ibdata1 文件从 59M 跳到了 323M。该特定表的 .ibd 文件减少了，但服务器的 ibdata1 文件变得疯狂。有任何想法吗？
我有一个生产服务器
2011年11月5日ibdata大小为100G。大约3个月就增加到200G，所以它的大小刚刚增加了一倍。所以它是一个巨大的数据。目前lvm是251G。
我几乎所有的表都带有 Innodb。我没有在每个表中使用 innodb。我在lvm上有我的idbata。所以我应该增加多少以备将来使用..？
或任何其他处理场景的最佳方式。
我正在处理一组非常大的数据库，这些数据库都是 innodb。
为了我的舒适，我在 mysql restart 上多次提到这个：
ibdata files do not match the log sequence number
但是，当该消息发生时，我已经清楚地看到 mysql 在重新启动之前正确关闭。
然后它“修复”到原始序列号，没有丢失任何东西。
永久处理和修复此问题的最佳方法是什么？
使用 Percona innodb_file_per_table=1
示例日志：
InnoDB: Initializing buffer pool, size = 80.0G
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 475575972691 and 475575972691 in ibdata files do not match the log sequence number 925369860131 in the ib_logfiles!
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information …我们有一个主动/被动拓扑，其中有两个共享原始存储的 x86 复合体，其中在给定时刻只有一个节点可以访问共享存储（也称为主动节点）。如果主动节点发生故障转移，被动节点将启动接管并成为可以访问共享存储的主动节点。每个节点都有自己的带有文件系统的引导设备存储。但是，共享存储上不能安装文件系统。
我们有兴趣在两个节点上安装 MySQL，它的数据驻留在共享存储中，只有活动节点运行服务器。
带有 InnoDB 的 MySQL 能够在原始设备上运行，并且还有关于如何在类似于我们的拓扑的集群上运行MySQL的指南。但是，在第二个示例中，它们确实在共享存储上安装了一个文件系统。文件系统问题引起了一个主要问题：
ib_logfile* 仍然需要一个文件系统。所以原始的 MySQL 功能并不完全是原始的。如果我错了，请纠正我。是否有将这些文件存储在原始存储中的解决方法？我们可以将重做日志 ( ib_logfile0, ib_logfile1)保存在节点的引导设备中，并始终在服务器启动之前删除这些文件（因此在多次故障转移的情况下我们不会有旧的日志文件）。但是，这可能会导致未提交的事务在事务中间失败的情况下被部分提交，从而与事务的整体思想相矛盾。
在此拓扑中，是否还有其他文件/功能可能会影响 mysql 的行为？
我有一个数据库，其整个大小约为 44GB，其中 ibdata1 约为 35GB。这没有意义，因为数据的大小不应超过 10GB。
我使用以下查询来估计数据大小：
SELECT CONCAT(table_schema, '.', table_name),
CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows,
CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA,
CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx,
CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size,
ROUND(index_length / data_length, 2) idxfrac
FROM information_schema.TABLES
ORDER BY data_length + index_length DESC
LIMIT 30;
任何想法如何清理 ibdata1 以及它为什么增长这么多？
顺便说一句，我使用 innodb_file_per_table
我已经安装了一个带有 InnoDB 的 MySQL 集群（随后启用了 innodb_file_per_table），但是由于我切换到 innodb_file_per_table，文件 ibdata1 增长（每月 2GB）。
my.cnf文件是否正确？服务器配置：
Debian 6 amd64
mysql-client-5.1 5.1.61-0+squeeze1
我的 InnoDB 配置文件：
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/lib/mysql
innodb_file_per_table
innodb_buffer_pool_size = 5G
innodb_additional_mem_pool_size = 48M
innodb_log_files_in_group = 3
innodb_log_file_size = 512M …我发现我的MariaDB的ibdata文件不断增加。所以，我搜索了这个，发现innodb_file_per_table应该设置为1。但是，我的DBMS的配置已经设置为1；
为什么 ibdata 文件大小不断增加以及我还应该为此做什么。
以下是我的 dbms 信息。
DBMS: MariaDB
engine: InnoDB Engine
version: 10.3
** my.cnf **
innodb_file_per_table=ON
transaction-isolation=READ-COMMITTED