web-dev-qa-db-ja.com

既存のサーバーのMySQL 5.6でundodataログをibdata1の外に移動できますか?

Innodbでfile-per-tableを使用しても縮小できないibdata1のサイズが大きいことを心配してきました

元に戻すログファイルを外部に移動することは理にかなっているように見えますが、この手順はかなり複雑に見えます。

http://dev.mysql.com/doc/refman/5.6/en/tablespace-splitting-undo.html

ライブサーバーでこれを達成する実践的な経験は誰にもありますか?

この行は、mysqlがすでにインストールされて実行されている場合は不可能であるように聞こえます。

this feature can only be enabled when initializing a MySQL instance

もう遅すぎる?

4
ck_

@ ohlin's answer には適切な回避策がありますが、それでも、MySQLインスタンス全体を、希望どおりに設定された取り消しログでセットアップする必要があります。次に、アプリケーションを新しいMySQLインスタンスにフェイルオーバーする必要があります。それでも、コード内のIPアドレスの変更やDNSの変更により、アプリケーションの観点から数分の論理的なダウンタイムが発生します。

元の質問

既存のサーバーのMySQL 5.6でundodataログをibdata1の外に移動できますか?

答えは間違いなくNOです。どうして ?次の図を考える

InnoDB Architecture

元に戻すログの場所については、次のオプションを確認してください

オプション#1:システムテーブルスペース内のログを元に戻す

デフォルトでは、元に戻すログは、ibdata1と呼ばれるシステムテーブルスペースファイルにあります。元に戻すログは、多くのトランザクションに直面して最大の制御されない増加の原因でした(私の投稿を参照してください innodb_file_per_tableが設定されている場合でも、Innodb ibdata1ファイルは5倍に増加できますか?

Ibdata1を再配置するには、 innodb_data_home_dirinnodb_data_file_path 。これらはグローバル変数ですが、動的ではありません。これらの設定を変更するにはmysqlの再起動が必要になるため、ibdata1内に埋め込まれている元に戻すログをライブMySQLインスタンスに移動することはできません。

オプション#2:システムテーブルスペース外のログを元に戻す

異なるディスクに元に戻すログを構成するオプションがあります。

  • innodb_undo_logs :トランザクション内で使用されるロールバックセグメントの数は増減できますが、システムに物理的に存在するロールバックセグメントの数は決して減少しません。したがって、後で必要とされないロールバックセグメントの割り当てを回避するために、このパラメーターの低い値から開始して徐々に増加させることができます(MySQLドキュメント)
  • innodb_undo_tablespaces
  • innodb_undo_directory

innodb_undo_tablespacesinnodb_undo_directory はどちらもグローバル変数ですが、動的ではありません。これらの設定を変更するにはmysqlの再起動が必要になるため、ibdata1の外部にある元に戻すログをライブMySQLインスタンスに移動することはできません。

エピローグ

この質問を読んだとき、それは 異なるディスク上にInnoDBを構成したFaceBook DBエンジニアからのブログ を思い出させました。

私の投稿で彼のブログを参照しました 挿入、更新、削除の操作を通じて1日に書き込まれるデータ量を確認するにはどうすればよいですか?

このアイデアでも、元に戻すディスクを別の場所に設定する必要があります。 mysqlの実行後にこれを行うことは不可能です。

4
RolandoMySQLDBA

@ RolandoMySQLDBA は、 MySQL INNODBストレージエンジン をクリーンアップする方法についての良い記事を持っています。基本的に、彼が言っているのは、ライブサーバーではそれほど簡単ではないということです。

ただし、 innodb-undo-tablespace について読んでいるときに、目的の設定で新しいサーバーを設定し、それを次のようにライブサーバーにリンクするオプションについて言及していることに気付きました奴隷。

(7)これらのオプションの理想的な設定を使用して、新しい本番インスタンスをデプロイします。 レプリケーション構成でスレーブサーバーとしてセットアップするか、または以前の本番インスタンスからデータを転送します。

その後、複製により、新しいサーバーにすべてのデータが含まれるようになります。この方法ですべてを設定し、変更している間に数分間システムを停止して、(希望する設定の)スレーブがマスターになるようにする必要があります。これは一時的な解決策であり、最初のサーバーの設定に必要な変更を加える機会が与えられます。

私はこれを自分で試したことはありません。私は通常、データベースをダンプし、新しい正しい設定でインストールする古い方法を使用します。上記の私の提案は少しトリッキーですが、他に選択肢がない場合は、試す価値があります。

1
Ohlin