MyISAM 數據庫的 InnoDB 錯誤和崩潰？
我有一台伺服器和一個只包含 MyISAM 表的 mysql 數據庫。伺服器上沒有其他數據庫（當然除了系統數據庫）。由於它移至 mysql 5.7.27，因此存在與 InnoDB 相關的錯誤甚至崩潰。該配置主要是 Ubuntu 18.04 軟體包附帶的預設配置，我只是調整了一些 myisam 緩衝區和記憶體。（現在我還增加了 innodb 池的大小，希望它能讓這些錯誤消失）
什麼可能導致這些錯誤以及我如何擺脫它們？
錯誤範例：
2019-09-19T04:39:34.464347Z 5169718
$$ Warning $$InnoDB：很難在緩衝池中找到空閒塊（21 次搜尋迭代）！21 次刷新頁面的嘗試失敗！考慮增加緩衝池大小。在您的 Unix 版本中，fsync 也可能非常慢，或者完全凍結在作業系統核心中。然後升級到更新版本的作業系統可能會有所幫助。查看下面診斷資訊中的 fsync 數量。待刷新（fsync）日誌：0；緩衝池：0。22967494 作業系統文件讀取，55308825 作業系統文件寫入，1252 作業系統 fsync。啟動 InnoDB Monitor 以將進一步的診斷資訊列印到標準輸出。 2019-09-20T08:27:30.209263Z 0
$$ ERROR $$ $$ FATAL $$InnoDB：頁面$$ page id: space=45, page number=4551 $$仍然固定或骯髒 2019-09-20 10:27:30 0x7f9350594740 InnoDB：文件 ut0ut.cc 第 910 行中的執行緒 140270684948288 中的斷言失敗
Innodb 表：
+--------------------+---------------------------+ | table_schema | table_name | +--------------------+---------------------------+ | information_schema | COLUMNS | | information_schema | EVENTS | | information_schema | OPTIMIZER_TRACE | | information_schema | PARAMETERS | | information_schema | PARTITIONS | | information_schema | PLUGINS | | information_schema | PROCESSLIST | | information_schema | ROUTINES | | information_schema | TRIGGERS | | information_schema | VIEWS | | mysql | engine_cost | | mysql | gtid_executed | | mysql | help_category | | mysql | help_keyword | | mysql | help_relation | | mysql | help_topic | | mysql | innodb_index_stats | | mysql | innodb_table_stats | | mysql | plugin | | mysql | server_cost | | mysql | servers | | mysql | slave_master_info | | mysql | slave_relay_log_info | | mysql | slave_worker_info | | mysql | time_zone | | mysql | time_zone_leap_second | | mysql | time_zone_name | | mysql | time_zone_transition | | mysql | time_zone_transition_type | | sys | sys_config | +--------------------+---------------------------+版本
mysql> show global variables like '%version%'; +-------------------------+-------------------------+ | Variable_name | Value | +-------------------------+-------------------------+ | innodb_version | 5.7.27 | | protocol_version | 10 | | slave_type_conversions | | | tls_version | TLSv1,TLSv1.1 | | version | 5.7.27-0ubuntu0.18.04.1 | | version_comment | (Ubuntu) | | version_compile_machine | x86_64 | | version_compile_os | Linux | +-------------------------+-------------------------+
我有一些煩人的消息要告訴你。MySQL 5.7 永久啟用了 InnoDB。它在文件中：
重要的
InnoDB 不能被禁用。–skip-innodb 選項已棄用且無效，並且使用它會導致警告。它將在未來的 MySQL 版本中刪除。這也適用於它的同義詞（–innodb=OFF、–disable-innodb 等）。
InnoDB 表的數量隨著版本的增加而增加。
Apr 04, 2018我在我的舊文章將XtraBackup 從 MySQL 5.6 恢復到 MySQL 5.7中提到了這一點MySQL 模式文件
MySQL 模式中的 InnoDB 表的數量也在主要版本之間發生變化。
早在 2017 年 12 月 9 日，我回答了ERROR 1031 (HY000): Table storage engine for ‘proc’ doesn’t have this option並討論了 InnoDB 表何時開始在 MySQL 模式中使用。
在 MySQL 5.6 中，它是 5 個表。在 MySQL 5.7 中，增加到 19 個。在 MySQL 8.0 中，所有 31 個表都是 InnoDB
在我的舊文章中，我說 MySQL 5.7 在
mysql架構中有 19 個 InnoDB 表。為了正確地尋找你的 InnoDB，執行這個
SELECT table_schema,table_name FROM information_schema.tables WHERE engine='InnoDB';
mysql應該出現架構中的 19 個表。如果你有額外的 InnoDB 表，你將不得不擺脫或重建這些表。如果此查詢未顯示 19 個表，則必須修復此問題。我剛剛注意到你在你的問題中說：
Since it moved to mysql 5.7.27 there are InnoDB related errors and even crashes如果您沒有正確升級系統表，mysqld 可能正在尋找
mysql模式表為 InnoDB。請閱讀有關 mysql_upgrade 的 MySQL 5.7 文件並查看–upgrade -system-tables。它應該將
mysql模式表從 MyISAM 轉換為 InnoDB。請事先在測試環境中執行此操作。
更新 2019-09-20 18:09 EDT
在一個愉快的聊天會話之後，事實證明有很多臨時表正在生成。所有的臨時表都使用 InnoDB，消耗了 482MB 的 InnoDB 緩衝池。InnoDB 緩衝池預設為 (128M)。增加512M以上就解決了。
我還建議將每個切換到 InnoDB。