web-dev-qa-db-ja.com

アクティブ/パッシブトポロジのrawデバイス上のMySQL InnoDB

アクティブ/パッシブトポロジがあり、2つのx86コンプレックスが共有rawストレージにあり、特定の瞬間に1つのノードのみが共有ストレージ（アクティブノード）にアクセスできます。アクティブノードでフェイルオーバーが発生した場合、パッシブノードがテイクオーバーを開始し、共有ストレージへのアクセス権を持つアクティブノードになります。各ノードには、ファイルシステムを備えた独自のブートデバイスストレージがあります。ただし、共有ストレージにファイルシステムをマウントすることはできません。

MySQLを両方のノードにインストールすることに興味があります。そのデータは共有ストレージにあり、アクティブノードのみがサーバーを実行しています。

MySQLとInnoDBはrawデバイスで実行できます 、および実行方法に関するガイドもあります MySQLをトポロジーに似たクラスターで 。ただし、2番目の例では、共有ストレージにファイルシステムがマウントされています。ファイルシステムの問題は大きな懸念を引き起こします：

ib_logfile *には引き続きファイルシステムが必要です。したがって、未加工のMySQL機能は完全に未加工のものではありません。間違えたら訂正してください。これらのファイルをrawストレージに保存するための回避策はありますか？ REDOログ（ib_logfile0、ib_logfile1）ノードの起動デバイスで、サーバーが起動する前にそれらのファイルを常に削除します（したがって、複数のフェイルオーバーが発生した場合に古いログファイルはありません）。ただし、これにより、トランザクションの途中で障害が発生した場合に、コミットされていないトランザクションが部分的にコミットされる可能性があり、トランザクションの概念全体と矛盾します。

このトポロジでmysqlの動作に影響を与える可能性のある他のファイル/機能はありますか？

mysqlinnodbfailoveribdata
5
Mattan

InnoDBの先読みログ（WAL）であるib_logfile *だけがファイルシステムを必要とするわけではないことに注意してください。あなたが持っている：

  1. おそらくMyISAMストレージエンジンを使用するmysqlスキーマのシステムテーブル（.frm、.MYD、.MYI（テーブルごと））（ほとんどは5.7でInnoDBを使用しています）
  2. 共有システムテーブルスペースを使用している場合でも、各InnoDBテーブルの.frmファイル（必要なテーブルメタデータ）
  3. MySQLログファイル（エラーログ、一般ログ、バイナリログ）
  4. SSLアーティファクト
  5. auto.cnf（MySQLインスタンスUUIDが生成され、自動的に保存される場所）
  6. 各スキーマのdb.optファイル（/<datadir>/<schema>/内）
  7. パーティションテーブルを作成する場合の.parファイル（5.7に移行）
  8. トリガーを作成する場合の.trnおよび.trgファイル
  9. InnoDB tmpテーブルスペース（5.6以降）
  10. 永続的なバッファープールページマップ（ib_buffer_pool、5.6以降）

上記のすべては、datadir=/some/valid/fs/pathがある限り、通常 dataディレクトリ 内にあります-これも複製されます（例：DRBD）または2つのノード間で共有（例：NFS、GFS、OCFS）-それで問題ありません。

.frm、.par、.trn、.trg、および.optファイルは、 新しいデータディクショナリ で削除されることに注意してください。

今後数か月の間に行われるいくつかの大きな発表をお楽しみに！ :)

RAWデバイスを使用している理由がわかりません。あなたには理由があると思います。 :)

幸運を！

3
Matt Lord

Rawストレージテクニックは、 innodb_file_per_table が無効になっているibdata1にのみ有効です。

私はこれを数回設定することを述べました

Note InnoDBアーキテクチャ（Percona CTO Vadim Tkachenkoからの画像）

InnoDB Plumbing

innodb_file_per_table を無効にすると、すべてのInnoDBテーブルのデータとインデックスが、二重書き込みバッファー、挿入バッファー、データディクショナリ、ロールバックセグメント、および元に戻すスペースとともに、未加工ストレージ内に配置されます。

REDOログに関しては、そのフォルダーに/var/lib/mysqlとib_logfile0を付けて、ib_logfile1を保持するだけの小さなDRBDブロックデバイスを用意することを検討してください。したがって、フェイルオーバーは次のようになります

  • 2つのサーバー間でDRBDを中断する
  • 新しいサーバーのDRBD状態をPrimary/Unknownに設定します
  • DRBDを/var/lib/mysqlにマウント
  • Ibdata1の情報でrawデバイスをマウントします
  • service mysql start
  • DRBDデバイスの同期
  • セットアップ Pacemaker / carp 次のフェイルオーバーのために準備するサービス

フェイルオーバー設定にはDRBD/ucarpを使用しました。 それらに関する私の古い投稿を参照

UPDATE 2015-10-14 11:30 EDT

すでに述べたように、REDOログは/var/lib/mysqlにマウントされたDRBDブロックデバイスにある必要があります。次のような他の重要なファイルに関して

  • バイナリログ
  • リレーログ
  • エラーログ
  • 遅いログ
  • 一般ログ

これらのファイルもすべて/var/lib/mysqlに含まれている必要があります。このようにして、フェイルオーバーはMySQLに関連するすべてのものを転送します（独自のディスクにあるRawデータを除く）。

[〜＃〜]警告[〜＃〜]：この設定はMyISAMテーブル用ではありません。ハードフェイルオーバーが発生すると、クラッシュ/フェイルオーバーの前に開いているすべてのMyISAMテーブルが破損しているとマークされ、影響を受けるすべてのMyISAMテーブルでREPAIR TABLEを実行する必要があります。

すべてのテーブルがInnoDBの場合は、この警告を無視してください。残りのMyISAMテーブルをInnoDBに変換する場合は、この警告を無視できます。 （mysqlスキーマのMyISAMテーブルをInnoDBに変換しないでください）。

2
RolandoMySQLDBA