ストレージエンジンをインストールしている環境でのリストアではまりがちなこと

TL;DR

• plugin_dir に必要な .so ファイルを置いておくのは大前提
• mysqldump から戻す時は、戻す前に自分で INSTALL PLUGIN
• 物理バックアップから戻すときは基本的にそのまま戻して起動すればおｋ

---

周囲1mくらいで2回聞かれたのでメモしておく。
対象は ストレージエンジンプラグイン (デーモンプラグインである innodb_memcached とか mysqlx は対象外）かつサーバーデフォルトで有効になって いない もの（ InnoDB, MyISAM などは対象外）、つまりだいたい Mroonga, TokuDB, RocksDB あたりをターゲットとして見ている。

ストレージエンジンプラグインが有効化されるタイミングは、 INSTALL PLUGIN または mysqldの起動時に mysql.plugin にレコードがある の2つ。

プラグインは plugin_dir （$basedir/lib/plugin とか、 x86_64のrpm版だったら /usr/lib64/mysql/plugin とか）に置いてあるファイル以外は読めないので、 どちらの場合も plugin_dir に対応する .so ファイルが設置済である必要がある。

という訳で、リストア先の plugin_dir に .so ファイルを置いていない場合は最初に置いておく。
TokuDB とか RocksDB とかのバンドルされている(= plugin_dir に .so ファイルは置いてある）けど有効化されていないストレージエンジンであればこの前提は既に満たされている。
MySQLで Mroonga を使っている時に置き忘れるパターンがほぼほぼ（MariaDBの場合はMroongaは「バンドルされているけど有効化されていないストレージエンジン」なのでMariaDBの場合は当てはまらないと思うけど最近もまだバンドルされているのかよくわからない…）

次。

物理バックアップから mysql スキーマを含んだ完全な datadir を戻す場合、特に気にする必要はない。
何故ならその mysql.plugin テーブルには既にその .so ファイルを示すレコードがINSERTされているので（バックアップ元のサーバーで INSTALL PLUGIN をした時点で、プラグインが有効化されると同時に mysql.plugin に INSERT が走る）、次に mysqld を起動した段階でそのストレージエンジンは有効化される。

物理バックアップでも、 mysql スキーマを 含まない datadir を戻す場合は、 mysql.plugin にレコードがないことが期待できるので、リストアする前にリストア先のインスタンスで INSTALL PLUGIN を実行する必要がある（なんなら INSERT INTO mysql.plugin VALUES (..) でもいいけど、わざわざSQLで叩く必要はないから INSTALL PLUGIN の方がいいと思う）

というか今日日こういう取り方することは少ないと思うけれども。

論理バックアップの場合、必ずリストア前に INSTALL PLUGIN が要る。
mysql スキーマを含んでいない場合は物理バックアップの時と同じくだが、全体をまるっとリストアする場合でも、 mysql.plugin への INSERT はプラグインを有効化 しない ので、 mysql スキーマのリストアまでは成功したとしても後続（単純にASCII順に並べる気もするから、前ってこともあり得る）のスキーマをリストアするどこかで失敗する（ sql_modeのNO_ENGINE_SUBSTITUTION が設定されている場合はエラー、されていない場合はワーニングでデフォルトのストレージエンジン（たぶんInnoDB）に勝手に置き換えられる）

もしどうしても論理バックアップで INSTALL PLUGIN をせずにやるとしたら、

1. mysql スキーマだけを先にリストアする
2. mysqld 再起動（これにより mysql.plugin のレコードが読まれてプラグインが有効化）
3. 残りのスキーマ、もしくは mysql スキーマも含めてもう一度リストアする
   という感じになる。敢えてやる必要はどこにもないと思うけれど。

というわけで、

• 論理バックアップから戻す時は自分で INSTALL PLUGIN
• 物理バックアップから戻す時はそのままでおｋ
  なのでしたん。

​