问题[innodb](server)

我们正在为我们的一个客户管理一个 MySQL 服务器，该客户拥有超过 100 个数据库，每个数据库大约有 50 个表，其中许多是 InnoDB 表。服务器崩溃了，我正试图找到罪魁祸首。重新启动时innodb_force_recovery = 2，我可以连接并且在 error.log 中看不到任何错误。更重要的是，mysqlcheck --all-databases所有表格都报告“Ok”。但是当我删除时innodb_force_recovery，服务器再次崩溃，将堆栈跟踪写入 error.log 并且只能使用kill -9.

在这些情况下，我应该如何找到有问题的数据库，以及什么会导致 mysqlcheck 错过损坏的表？请不要告诉我忽略它并从转储中恢复所有数据库。这对于一个或两个数据库来说可能是可以接受的，如果它在蓝月亮中只发生一次，但是我不止一次在同一台服务器上遇到问题，从转储中恢复所有内容只需要太多时间和手动工作才能做到这一点时间。

服务器版本为 5.5.46 并且innodb_file_per_table处于活动状态。

按要求摘录 error.log（是否The tablespace free space info is corrupt意味着存在不在特定表中且无法更正的错误？）：

180222 17:13:48 mysqld_safe Starting mysqld daemon with databases from /home/mysql
180222 17:13:48 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
180222 17:13:48 [Note] /usr/libexec/mysqld (mysqld 5.5.46) starting as process 26242 ...
180222 17:13:48 [Note] Plugin 'FEDERATED' is disabled.
180222 17:13:48 InnoDB: The InnoDB memory heap is disabled
180222 17:13:48 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
180222 17:13:48 InnoDB: Compressed tables use zlib 1.2.3
180222 17:13:48 InnoDB: Using Linux native AIO
180222 17:13:48 InnoDB: Initializing buffer pool, size = 128.0M
180222 17:13:49 InnoDB: Completed initialization of buffer pool
180222 17:13:49 InnoDB: highest supported file format is Barracuda.
180222 17:13:49  InnoDB: Waiting for the background threads to start
180222 17:13:50 InnoDB: 5.5.46 started; log sequence number 1632912830888
180222 17:13:50 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180222 17:13:50 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180222 17:13:50 [Note] Server socket created on IP: '0.0.0.0'.
180222 17:13:50 [Note] Event Scheduler: Loaded 0 events
180222 17:13:50 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.46'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi
InnoDB: Dump of the tablespace extent descriptor:  len 40; hex 000000000000000200000000061600000000126e00000004ffffffffffffffffffffffffffffbfaa; asc                    n                    ;
InnoDB: Serious error! InnoDB is trying to free page 512
InnoDB: though it is already marked as free in the tablespace!
InnoDB: The tablespace free space info is corrupt.
InnoDB: You may need to dump your InnoDB tables and recreate the whole
InnoDB: database!
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
180222 17:13:50  InnoDB: Assertion failure in thread 2499464080 in file fsp0fsp.c line 3309
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:13:50 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=268435456
read_buffer_size=1048576
max_used_connections=0
max_threads=512
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1314506 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x33)[0x842a1f3]
/usr/libexec/mysqld(handle_fatal_signal+0x42b)[0x82d9d3b]
[0x7bc420]
[0x7bc410]
/lib/libc.so.6(gsignal+0x50)[0x626b10]
/lib/libc.so.6(abort+0x101)[0x628421]
/usr/libexec/mysqld[0x85012e7]
/usr/libexec/mysqld[0x850147e]
/usr/libexec/mysqld[0x849c0b1]
/usr/libexec/mysqld[0x84a8a61]
/usr/libexec/mysqld[0x8561fef]
/usr/libexec/mysqld[0x85570a9]
/usr/libexec/mysqld[0x847b082]
/usr/libexec/mysqld[0x846bf04]
/usr/libexec/mysqld[0x846dad4]
/lib/libpthread.so.0[0x50d912]
/lib/libc.so.6(clone+0x5e)[0x6d347e]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
180222 17:13:50 mysqld_safe Number of processes running now: 0
180222 17:13:50 mysqld_safe mysqld restarted

我试图弄清楚如何为 MySQL 中的用户设置磁盘空间限制。我想要的是，例如，管理员为用户 A 分配 1G 磁盘空间，如果 A 用完 1G 磁盘空间，MySQL 将不允许 A 插入任何东西。我google了这个问题，有人提到可以通过使用表空间来解决，但没有提到如何。任何帮助表示赞赏。

我发现许多网站都在谈论这样做，但我错过了一些重要的细节。一般步骤是

• 跑FLUSH TABLES WITH READ LOCK
• 拍摄 ZFS 快照
• 跑UNLOCK TABLES

各种消息来源报告说，我正在使用的 InnoDB 实际上并不支持FLUSH. MySQL 用户手册指出有一个FLUSH TABLES...FOR EXPORT用于 InnoDB 的变体，但这需要单独指定每个表，而不是备份整个数据库。我宁愿避免单独指定每个表，因为表列表很有可能与实际存在的表不同步。

我遇到的另一个问题是我计划做类似的事情mysql -h"$HOST" -u"$USERNAME" -p"$PASSWORD" --execute="FLUSH TABLES WITH READ LOCK"。但是，这会在会话退出后立即解除锁定。这是有道理的，但也很烦人，因为我在拍摄快照时需要持有读锁。

我的另一个想法是使用 Percona XtraBackup 之类的工具进行热备份并拍摄备份快照，但我不想支付将所有数据写入第二个位置的成本，只是为了对其进行快照。

MySQL 不断在我的服务器上崩溃。我正在使用 VestaCP 运行几十个站点，并且几个月来没有遇到 MySQL 问题。

我在具有 12GB 内存的 Linode VPS 上运行，通常其中 9GB 是免费的。

MySQL 错误日志如下所示：

160711 22:32:36 [Note] Plugin 'FEDERATED' is disabled.
160711 22:32:36 InnoDB: The InnoDB memory heap is disabled
160711 22:32:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160711 22:32:36 InnoDB: Compressed tables use zlib 1.2.8
160711 22:32:36 InnoDB: Using Linux native AIO
160711 22:32:39 InnoDB: Initializing buffer pool, size = 1.0G
InnoDB: mmap(1098907648 bytes) failed; errno 12
160711 22:32:39 InnoDB: Completed initialization of buffer pool
160711 22:32:39 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160711 22:32:39 [ERROR] Plugin 'InnoDB' init function returned error.
160711 22:32:39 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160711 22:32:39 [ERROR] Unknown/unsupported storage engine: InnoDB
160711 22:32:39 [ERROR] Aborting

160711 22:32:39 [Note] /usr/sbin/mysqld: Shutdown complete

160711 22:33:43 [Note] Plugin 'FEDERATED' is disabled.
160711 22:33:43 InnoDB: The InnoDB memory heap is disabled
160711 22:33:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160711 22:33:43 InnoDB: Compressed tables use zlib 1.2.8
160711 22:33:43 InnoDB: Using Linux native AIO
160711 22:33:43 InnoDB: Initializing buffer pool, size = 1.0G
160711 22:33:43 InnoDB: Completed initialization of buffer pool
160711 22:33:43 InnoDB: highest supported file format is Barracuda.

这组特定的错误似乎是在发出service mysql restart命令后发生的。

我花了很多时间查看这个特定的错误：Fatal error: cannot allocate memory for the buffer pool. 我发现的一切都表明缺少 ram 是问题所在，大多数人都使用极低内存系统（通常为 512MB 左右）。显然，在 12GB 的内存和 9GB 的空闲内存下，内存不足应该不会有问题，所以我不确定在这种情况下该怎么做。

运行free -h产生以下结果：

free -h 的命令行结果 此外，日志文件中有大量条目，如下所示：

160711 22:31:58 [Warning] Aborted connection 5131 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:31:58 [Warning] Aborted connection 5127 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:00 [Warning] Aborted connection 5136 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5134 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5133 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5112 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5135 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:04 [Warning] Aborted connection 5137 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:05 [Warning] Aborted connection 5140 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)

最后，我确实尝试将 InnoDB 缓冲池的大小从 512MB 增加到 1GB，但这似乎没有帮助。我是否只是增加缓冲池大小直到它停止崩溃？

编辑：感谢到目前为止的回复！这是我当前的 my.cnf：

[client]
port=3306
socket=/var/run/mysqld/mysqld.sock

[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
log-warning=2
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log
#skip-networking

symbolic-links=0

skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 256M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

#innodb_use_native_aio = 0
innodb_file_per_table

max_connections=1500
max_user_connections=200
wait_timeout=10
interactive_timeout=50
long_query_time=5

innodb_log_buffer_size          = 32M
innodb_buffer_pool_size         = 1024M
innodb_log_file_size            = 768M

!includedir /etc/mysql/conf.d/

我正在迁移到 RDS 上的 MariaDB。我的表已启动并正在运行，一切看起来都不错，但鉴于我使用的是 MariaDB 10.0.24，我正在考虑将我的几个 MyISAM 表切换到 Innodb。在此之前，我需要使用 MyISAM，因为 InnoDb 不支持全文。但是，据我了解，MariaDB > 10.0.5 支持在 InnoDB 上进行全文搜索。

在我的第一次尝试中，我使用以下方法将表从 MyISAM 转换为 InnoDB：

ALTER TABLE `courses` ENGINE=INNODB

但在那之后，我的 FULLTEXT 索引似乎已被重置。它们仍然列在那里，但不响应全文搜索。

Can't find FULLTEXT index matching the column list

此外，当我尝试在表上创建新的 FULLTEXT INDEXES 时，我无法再创建它们——只有 INDEX 和 UNIQUE 可用。

最后，虽然我在我的 RDS 参数组中看到允许我配置 INNODB FULLTEXT 设置的设置，但我没有看到任何可以让我“打开它”的设置，所以我假设它默认是打开的。

我是否坚持使用 MyISAM，或者是否可以将这些表更改为 InnoDB，而我只是还没弄清楚该怎么做？

谢谢你的帮助！

更新：

显示创建表：

CREATE TABLE `courses` (
  `id` varchar(32) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `instructor_id` varchar(32) DEFAULT NULL,
  `catalog_id` varchar(32) NOT NULL,
  `site_id` varchar(32) NOT NULL,
  `created_on` datetime NOT NULL,
  `modified_on` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `site_id` (`site_id`),
  KEY `instructor_id` (`instructor_id`),
  KEY `catalog_id` (`catalog_id`),
  FULLTEXT KEY `name_description` (`name`,`description`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

询问：

SELECT `c`.*, (MATCH (c.name) AGAINST ('+yoga*' IN BOOLEAN MODE)) AS `nameRelevance`, (MATCH (c.description) AGAINST ('+yoga*' IN BOOLEAN MODE)) AS `descriptionRelevance` FROM `courses` AS `c` WHERE (c.catalog_id IN ('xxxxx')) AND (c.site_id = 'yyyyy') AND (MATCH (c.name, c.description) AGAINST ('+yoga*' IN BOOLEAN MODE) OR MATCH (c.name, c.description) AGAINST ('+yoga*' IN BOOLEAN MODE))

错误：找不到与列列表匹配的 FULLTEXT 索引

我在主键列上运行 DROP COLUMN（我知道，这很糟糕，但我必须这样做）。有一个进度指示器：

Stage: 1 of 2 'copy to tmp table'    107% of stage done

在操作过程中我没有修改数据。为什么会超过100%完成？它会停止吗？

伙计们，

我有一个大问题。有一台带有 CRM 数据库的服务器。我可能损坏了它，不知道该怎么办。

ls /var/lib/mysql/sugarcrm/
accounts_audit.frm      address_book.ibd     contacts_audit.frm           emails_email_addr_rel.ibd   mkt_marketiery_accounts_c.frm     pm_processmanagerstagetask.frm     quotes.frm              uni_webinars.frm
accounts_audit.ibd      bugs_audit.frm

等等。当我尝试观看或进行更改时，我收到

mysql> select * from vcals limit 1;
ERROR 1146 (42S02): Table 'sugarcrm.vcals' doesn't exist

mysqld.log：

130515 11:34:02130515 11:34:02 [错误] 尽管表的 .frm 文件存在，但无法从 InnoDB 的内部数据字典中找到表 sugarcrm/vcals。也许你已经删除并重新创建了 InnoDB 数据文件但忘记删除 InnoDB 表对应的 .frm 文件，或者你已经将 .frm 文件移动到另一个数据库？请参阅http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html 如何解决问题。

问题是我没有 .ibd 文件，只有 .frm。另外我还没有完整备份数据库的 .sql 文件。现在我从很久以前的 5 月 9 日导入了 .sql。:( 我知道 .frm 不包含数据，仅包含结构。

问题是：我能以某种方式修复还是这个数据库副本不可修复？一般来说，如果我有 .ibd 文件，可以使用什么方法来修复数据库？就我而言，5 月 9 日备份是我认为最好的变体。我没有出口，不是吗？

谢谢。

我有一个 Ubuntu 10.04 生产 MySQL 数据库服务器，其中数据库的总大小为 260 GB，而根分区的大小本身为 300 GB，其中存储了数据库，基本上意味着大约 96% 的 / 已满并且没有剩余空间用于存储转储/备份等。到目前为止，没有其他磁盘连接到服务器。

我的任务是将此数据库迁移到位于不同数据中心的其他服务器。问题是如何以最少的停机时间有效地做到这一点？

我在想：

• 请求将额外的驱动器附加到服务器并在该驱动器中进行转储。[编辑：现在不可能。]
• 将转储传输到新服务器，恢复它并使新服务器成为现有服务器的从属服务器以保持数据同步
• 当需要迁移时，中断复制，更新从属配置以接受读/写请求并将旧服务器设置为只读，这样它就不会接受任何写请求，并告诉应用程序开发人员使用新的 db IP 地址更新那里的配置。

你有什么建议来改进这个或任何其他更好的方法来完成这个任务？

插入下表最多需要 70 秒才能完成：

CREATE TABLE IF NOT EXISTS `productsCategories` (
  `categoriesId` int(11) NOT NULL,
  `productsId` int(11) NOT NULL,
  PRIMARY KEY (`categoriesId`,`productsId`),
  KEY `categoriesId` (`categoriesId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

表中大约有 100,000 行，占用磁盘空间 7MB。

MySQL中是否有一些可以提高写入性能的设置？

我的my.cnf文件如下：

log-slow-queries="/var/log/mysql/slow-query.log"
long_query_time=1 
log-queries-not-using-indexes

innodb_buffer_pool_size=4G
innodb_log_buffer_size=4M
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=8
innodb_flush_method=O_DIRECT

query_cache_size = 6G
key_buffer_size = 284M
query_cache_limit = 1024M
thread_cache_size = 128
table_cache = 12800

sort_buffer_size=2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M

read_buffer_size=128K

open_files_limit               = 1000
table_definition_cache         = 1024
table_open_cache               = 6000

max_heap_table_size=512M
tmp_table_size=4096M

max_connections=1000

thread_concurrency = 24

这是硬件设置：

• 戴尔R710
• RAID10
• 48G内存

鉴于此硬件，我不认为问题是硬件瓶颈。

我正在寻找使用 InnoDB 的 MySQL 5.6 的 ext3 文件系统块大小的建议。

在 NetApp FibreChannel LUN（块大小为 4k）上的 VMware ESXi 5、VMFS 5 数据存储中运行 CentOS 5.4 VM。使用 O_DIRECT，innodb_flush_log_at_trx_commit = 2，14G 缓冲池，数据库执行 OLTP，偶尔进行一些大查询处理大量数据。有些表有几 GB 或更多，有些则很小。表和 ibdata 文件在一个文件系统上，binlogs 和 ib_logfiles 在另一个文件系统上，所以它们可以有不同的块大小。

我知道 InnoDB 使用 16k 块大小，这不是用户可配置的，所以我想知道是否值得将 ext3 块大小设置为匹配，而不是默认的 4k。

谢谢！