システム カタログ › データベース アプライアンス › MYSQLR、MYSQLR64 - レプリケーションに適した MySQL データベース アプライアンス

MYSQLR、MYSQLR64 - レプリケーションに適した MySQL データベース アプライアンス

機能の概要

MYSQLR64 は、MySQL データベース エンジン（http://www.mysql.org）に基づいたデータベース アプライアンスです。 任意のアプリケーションにデータベースを簡単に追加できる方法を提供します。 このアプライアンスは、複雑な MYSQL レプリケーション シナリオでも使用できます。 アプライアンスは MYSQL5 （CentOS 5.5/MySQL）に基づいているだけでなく、データベース レプリケーションの処理も行います。

データベース レプリケーションでは、1 つの MySQL データベース サーバ（マスタと呼ばれる）から、1 つ以上の MySQL データベース サーバ（スレーブと呼ばれる）にデータをレプリケートできます。 MYSQLR64 アプライアンスは、マスタ/スレーブだけでなく、マスタ/マスタ レプリケーションおよび 3 つ以上のマスタを含めたレプリケーション用にセットアップできます。

レプリケーションのセットアップ、管理およびモニタリングは Web インターフェースを介して行います。 Web インターフェースは、マスタ上でゼロに近いダウンタイムでレプリケーションを開始する簡単な方法を提供します。 問題が発生した場合のレプリケーションの修復にも使用できます。 Web インターフェースを使用して、MYSQL や MYSQL5 などの古いデータベース アプライアンスからデータベースをコピーできます。 また、MYSQLR64 では、ユーザのデータベースを簡単に管理したり参照したりできます（phpMyAdmin に基づく）。

レプリケーションは以下のような状況で役立ちます。

• スケールアウト ソリューション - パフォーマンス（「マスタ/マスタ設定」）を改善するために複数のノード間に負荷を分散させます。
• フェールオーバ ソリューション - マスタ/マスタ レプリケーションで複数のノードを使用して、他が失敗した場合にそれぞれのアプライアンスのみを使用して、アプリケーションに対応できます。 （MYSQL サーバが失敗した場合、MYSQLR64 は自動的に障害に対応しないため、ユーザのアプリケーションで検出して、その使用を停止する必要があります。 )
• バックアップ ソリューション - 2 つ（または 3 つ以上）のノードを使用します。1 つはマスタ、もう 1 つはスレーブとして実行されます。 アプリケーションはマスタのみを使用します。スレーブは、バックアップ用に使用されます（その場合、バックアップの整合性を維持するためにデータベースを停止可能）。または、マスタをロードせずに、負荷の大きいデータの分析（データを変更しないレポート、サマリなど）を単に実行するために使用されます。 （MYSQLR64 は、データベースを自動的にバックアップしないので、ユーザが管理する必要があります。 )

そのデフォルト設定で、MYSQLR64 は管理用の Web インターフェースを備えた MYSQL5 アプライアンスとして正確に動作します。 レプリケーション シナリオに使用するには、適切に設定された少なくとも 2 つの MYSQLR64 アプライアンスを必要とします（「典型的な使用状況」を参照）。

MYSQLR64 は、各 MYSQLR64 インスタンス上で設定できるアプリケーション定義ボリューム上にデータベースを格納します。 空のボリューム上で起動されると、MYSQLR64 は自動的に空のデータベースを作成します。

重要： データベース ファイルは、マスタからスレーブへとそのままコピーされるため、レプリケーションを使用するときは 32 ビットと 64 ビット MYSQLR アプライアンスを一緒に使用しないでください。 また、アプライアンスの 32 ビット バージョンからのデータ ボリュームは、同じアプライアンスの 64 ビット バージョンと一緒に使用しないでください（その逆の場合も同様）。 32 ビットと 64 ビット MYSQLR バージョン間でデータベースをマイグレートするには、ここで説明されているように 1 つのホスト上のデータベースをダンプして他のホストにインポートします。

境界

リソース

端子

デフォルト インターフェースは有効です。 （SSH 経由の）診断およびトラブルシューティング用です。 このアプライアンスの今後のバージョンで SSH アクセスを無効にする可能性があります。
重要： rin 端子と rout 端子は SSH（tcp 22）および MYSQL（tcp 3306）データの両方に使用されます。 これらの端子の接続にゲートウェイ/VPN を使用する場合、この 2 つのポート許可するようにファイアウォールを設定します。

ユーザ ボリューム

データ ボリュームは、オプションで最上位のディレクトリに my.cnf ファイルを含めることができます。このファイルには MYSQL 設定オプションが含まれます。 詳細については、「カスタム設定」セクションを参照してください。 この機能は MYSQLR64 1.6.1 以降で利用可能です。

重要：

• データ ボリュームは MYSQL インスタンスに排他的に使用する必要があります（他のアプライアンスと共有できない）。
• データ ボリュームは、LVM ボリュームを構築するために使用されるため、ファイル システムでフォーマットしないでください。 ユーザが任意のファイル システム（古い MYSQL アプライアンスからのファイルを含む可能性がある）でフォーマットされたボリュームを使用した場合、アプライアンスは起動に失敗して、ユーザはデータベース/ファイルを削除できなくなります。

データベースを古いアプライアンス（MYSQL、MYSQL5、MYSQL64）、物理サーバ、または MYSQLR （32 ビットまたは 64 ビットのバージョンのアプライアンスからマイグレートする場合）からマイグレートするには、「別のアプライアンスからのデータベースのマイグレート」の手順を参照してください。

プロパティ

MYSQLR64 1.6.8 の時点で、use_old_passwords プロパティは削除されました。 old_passwords を有効にする必要がある場合は、以下で説明するとおりにカスタム設定を作成してください。

error_log_filename が指定されていて、log 端子が接続されていない場合、またはファイルシステムをマウントできない場合は、MYSQLR アプライアンスは起動に失敗します。

詳細プロパティ

カスタム設定

この機能は MYSQLR64 1.6.1 以降で利用可能です。

MYSQLR64 では、カスタム MYSQL 設定ファイルを使用できます。このファイルで、追加の設定オプションを提供するか、または /etc/my.cnf に指定された既存の設定を上書きすることができます。

カスタム設定を使用するには、my.cnf という名前のファイルを作成して、データ ボリュームの最上位ディレクトリに置きます。 ファイルの形式は MYSQL ドキュメントで説明されている MYSQL オプション ファイル構文に従う必要があります。

たとえば、InnoDB を使用する場合に、MYSQLR64 を調整して、パフォーマンスを向上させるには、以下の例を使用できます。 （デフォルト MYSQLR64 設定は MyISAM 用に最適化されています）。 この例は 512M のメモリ（MYSQLR64 のデフォルト）を使用することを前提にしています。

[mysqld]
# Shrink down MyISAM buffers
key_buffer=512K
myisam_sort_buffer_size=512K

# Make InnoDB the default storage engine (optional)
default-storage-engine = INNODB

# Set InnoDB buffer size
innodb_buffer_pool_size=350M
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb_thread_concurrency=8

# If you do not have too many tables use this option, so you will not have uncontrolled innodb main tablespace growth which you can’t reclaim.
innodb_file_per_table=1

重要： レプリケーション モードで使用する場合、レプリケーションを修正/開始する場合は常に、MYSQLR64 がデータ ボリューム上の my.cnf ファイルを同期するため、スレーブがマスタと同じ設定になります。

Web インターフェース

MYSQLR64 は、ui 端子およびCA 3Tera AppLogic エディタ内の［ログイン（Web）］オプションによるデフォルト インターフェースの両方でアクセスできる Web インターフェースを提供します。 Web インターフェースを使用するには HTTP 認証が必要です。 ユーザ名をブランクのままにして、パスワードとして web_pwd の値を使用します。 このインターフェースには以下の機能があります。

• サーバ ステータスの表示
  • 起動/停止/再起動 mysql サービス
  • mysql サーバ ステータスおよびアップタイム
  • mysql レプリケーション ステータス（このアプライアンス専用）
  • 最新の mysql ログ エントリ
  • アプライアンス アップタイム
  • アプライアンス メモリ使用量
  • アプライアンス ディスク使用量
• コンテンツのマイグレート（old_data ボリュームが存在する場合のみ表示可能）
  • コンテンツのマイグレート - データ ボリュームに old_data ボリュームのコンテンツをコピーします。 これは MYSQL および MYSQL5 アプライアンスからの容易なアップグレードを提供するために使用されます。 データ ボリューム上のデータがすべて消去されます。
• レプリケーションの表示/管理
  • mysql レプリケーション ステータス（このアプライアンス専用）
  • レプリケーションを開始/修正します。 この場合、アプライアンス上のデータベースは消去され、マスタからのレプリケーションが最初から開始されます。 これは、マスタ上のデータベースに影響しません（マスタ上のデータは削除されません）。さらに、マスタ MYSQLR64 アプライアンスのダウンタイムを引き起こすこともありません。 修復中、アプライアンスはオフラインになるため、使用しないでください。
  • スナップショットの削除 - このアプライアンスで、スレーブ上でレプリケーションを開始/修正するために作成されたデータベース スナップショットを削除します。 通常動作では、アプライアンス上にスナップショットは残らず、スナップショットの削除ボタンが表示される場合、スレーブが現在このアプライアンスからレプリケーションを開始しているか、または、前のレプリケーションを開始しようとする試行が失敗しています。 このオプションは、スナップショットを削除する前に、スレーブがスナップショットを使用していないことを確認するのに役立ちます。 アプライアンス上にスナップショットがなければ、このオプションは表示されません。
  • マスタ ログ ポジションのリセット - マルチノード マスタ マスタ レプリケーションでの新しいサーバを追加する場合、現在のアプライアンス上でレプリケーションの開始/修正を実行した後、「rout」端子経由でアプライアンスに接続するアプライアンスの Web インターフェースにログインし、［Reset Master Log Position］をクリックする必要があります。
• データベースの管理

PhPMyAdmin を使用して、ユーザのデータベースを参照し、編集します。

レプリケーション セットアップおよびメンテナンス

MYSQLR64 アプライアンスへのマスタ/スレーブ レプリケーションの追加

CA 3Tera AppLogic では、データの損失なしに、既存の MYSQLR64 アプライアンスへマスタ/スレーブ レプリケーションを追加することができます。

MYSQLR64 アプライアンスへのマスタ/スレーブ レプリケーションの追加方法

1. 既存のアプライアンス上で rpl_mode を master に設定します。
2. 新しい MYSQLR64 アプライアンスを、空のデータ ボリュームを持つアプリケーションへ追加します。 rout 端子を現在のアプライアンスの rin 端子へ接続します。
3. （オプション）マスタ/マスタ レプリケーション内で使用する場合は、現在のアプライアンス上の取り外された端子を新しいアプライアンスの rin 端子に接続します。
4. アプリケーションを再起動します。
5. 新しいアプライアンスの Web インターフェースにログインし、［Manage Replication］タブから initiate/fix レプリケーションを選択します。 マスタ上のデータのサイズに応じて、ログ記録には時間がかかります。 MYSQLR64 へのアクセスに INSSLR を使用する場合、必ずタイムアウト プロパティを高い値（36000）に設定してタイムアウトを避けるようにしてください。 クライアント側のどのプロキシにもタイムアウトがないことを確認してください（プロキシは全く使用しないことをお勧めします）。

レプリケーションが開始された後、両方の MYSQLR64 アプライアンス上の Web インターフェースにログインし、レプリケーション ステータスを確認します。 レプリケーションは両方のアプライアンス上で 5 分以内に実行されます。

マスタ/スレーブ レプリケーションへの MYSQLR64 アプライアンスの追加

CA 3Tera AppLogic では、既存のマスタ/マスタ レプリケーションに、データの損失なしに新しい MYSQLR64 アプライアンスを追加することができます。

マスタ/スレーブ レプリケーションへの MYSQLR64 アプライアンスの追加方法

1. 新しい MYSQLR64 アプライアンスを、空のデータ ボリュームを持つアプリケーションへ追加します。 たとえば、N-1 MYSQLR64 アプライアンス（3 <= N <= 10）がすでにあり、環状設定で各アプライアンスの rout 端子が隣のアプライアンスの rin 端子に接続されている（db1 rout が db2 rin に接続、というパターンが続く）ことを前提とした場合、dbN です。
2. rpl_mode を dbN の master_and_slave に設定します。
3. dbN-1 アプライアンスの rout 端子を、dbN アプライアンスの rin 端子に接続します。
4. dbN アプライアンスの rout 端子を、db1 アプライアンスの rin 端子に接続します。
5. 変更が有効になるように、アプリケーションを再起動します。 再起動の後、レプリケーションは手順の最後まで同期されません。 1 つのアプライアンスに書き込まれたデータは、この処理中は他のアプライアンス上では一切レプリケートされない場合があります。
6. 新しい dbN アプライアンスの Web インターフェースにログインし、［Manage Replication］タブから initiate/fix レプリケーションを選択します。 マスタ上のデータのサイズに応じて、ログ記録には時間がかかります。 MYSQLR64 へのアクセスに INSSLR を使用する場合、必ずタイムアウト プロパティを高い値（36000）に設定してタイムアウトを避けるようにしてください。 クライアント側のどのプロキシにもタイムアウトがないことを確認してください（プロキシは全く使用しないことをお勧めします）。
7. レプリケーションが開始された後、dbN-1 の Web インターフェースにログインし、［Reset Master Log Position］を選択します。 ログ記録により、アプリケーションは dbN-1、および dbN の最初からのバイナリ ログを読み取ります。

すべての MYSQLR64 アプライアンスの Web インターフェースの上へログインし、レプリケーション ステータスを検証します。レプリケーションは 5 分以内にすべてのアプライアンスで実行されます。

マスタ/スレーブ設定でのレプリケーション修復

CA 3Tera AppLogic では、データの損失なしに、マスタ/スレーブ設定でのレプリケーションを修復することができます。

マスタ/スレーブ設定でのレプリケーション修復方法

1. スレーブの Web インターフェースへのログインし、initiate/fix レプリケーションを選択します。 マスタ上のデータのサイズに応じて、ログ記録には時間がかかります。 操作中は、スレーブ上の mysql サービスは停止します。 マスタ上ではダウンタイムは発生しません。 この操作は既存の MYSQLR64 アプライアンスに新しいアプライアンスを追加することと同等です。 MYSQLR64 へのアクセスに INSSLR を使用する場合、必ずタイムアウト プロパティを高い値（36000）に設定してタイムアウトを避けるようにしてください。 クライアント側のどのプロキシにもタイムアウトがないことを確認してください（プロキシは全く使用しないことをお勧めします）。

レプリケーションが開始された後、スレーブ MYSQLR64 アプライアンス上の Web インターフェースにログインして、レプリケーション ステータスを検証します。レプリケーションは 5 分以内に実行されます。

マスタ/マスタ設定でのレプリケーション修復

CA 3Tera AppLogic では、マスタ/マスタ設定でのレプリケーションを、データの損失なしに修復することができます。

レプリケーションの失敗をレポートするアプライアンスの Web インターフェイスにログインし、initiate/fix レプリケーションを選択します。 マスタ上のデータベースのサイズに応じて、ログ記録には時間がかかります。 操作中は、スレーブ上の mysql サービスは停止します。 マスタ上ではダウンタイムは発生しません。 修復が終了するまで、データベースはマスタ間で同期化されません。 データベース更新は、修復の間他のすべての MYSQLR64 アプライアンス上でレプリケートされない場合があります。

このアプライアンス上のデータはすべてマスタから初期化されます。 レプリケーションが壊れているので、現在のアプライアンス上にデータベースに更新があれば、それらは失われます。 この場合は、競合を手動で解決してください。

マスタ/マスタ設定でのレプリケーション修復方法

1. fix レプリケーションを実行するアプライアンスに接続される rout 端子を持つ Web インターフェイスにログインします。 ［Reset Master Log Position］を選択します。 マスタ ログを設定すると、アプリケーションが修正されたアプライアンスのバイナリ ログを最初から読み取ります。 MYSQLR64 へのアクセスに INSSLR を使用する場合、必ずタイムアウト プロパティを高い値（36000）に設定してタイムアウトを避けるようにしてください。 クライアント側のどのプロキシにもタイムアウトがないことを確認してください（プロキシは全く使用しないことをお勧めします）。

すべての MYSQLR64 アプライアンスの Web インターフェースの上へログインし、レプリケーション ステータスを確認します。 5 分以内に、レプリケーションはすべてのアプライアンス上で実行されます。

レプリケーション モニタリング

MYSQLR64 アプライアンス間のレプリケーションをモニタするクローン ジョブがあります。 レプリケーションが有効になっている場合、このクローン ジョブは 2 分ごとに行われて、以下の場合にグリッド ダッシュボードにアラートを送信します。

• レプリケーションが実行されていない（グリッド ダッシュボードに次のメッセージが表示されます：マスタ サーバのレプリケーションが実行されていません。確認してください。）
• レプリケーションは実行されていますが、マスタから遅れすぎています（グリッド ダッシュボードに次のメッセージが表示されます：レプリケーションがマスタから大幅に遅れています。確認してください。）
• データ ボリューム上のディスク空き容量が低下している（空き容量 20% 未満）。 これは、レプリケーションが有効かどうかにかかわらず確認されます（グリッド ダッシュボードに次のメッセージが表示されます： データ ボリューム上の空き容量が低下しています。確認してください。）
• binlogs ボリューム上のディスク空き容量が低下している（空き容量 20% 未満）。 これは、レプリケーションが有効かどうかにかかわらず確認されます（グリッド ダッシュボードに次のメッセージが表示されます： binlogs ボリューム上の空き容量が低下しています。確認してください。）

このような場合、ユーザは手作業で問題を解決する必要があります。

レプリケーションが失敗した場合は、上のセクションで説明したようにし、Web インターフェースを使用して、修正できます。

レプリケーション モニタリング

MYSQLR64 アプライアンス間のレプリケーションをモニタするクローン ジョブがあります。 レプリケーションが有効になっている場合、このクローン ジョブは 2 分ごとに行われて、以下の場合にグリッド ダッシュボードにアラートを送信します。

• レプリケーションが実行されていない（グリッド ダッシュボードに次のメッセージが表示されます：マスタ サーバのレプリケーションが実行されていません。確認してください。）
• レプリケーションは実行されていますが、マスタから遅れすぎています（グリッド ダッシュボードに次のメッセージが表示されます：レプリケーションがマスタから大幅に遅れています。確認してください。）
• データ ボリューム上のディスク空き容量が低下している（空き容量 20% 未満）。 これは、レプリケーションが有効かどうかにかかわらず確認されます（グリッド ダッシュボードに次のメッセージが表示されます： データ ボリューム上の空き容量が低下しています。確認してください。）
• binlogs ボリューム上のディスク空き容量が低下している（空き容量 20% 未満）。 これは、レプリケーションが有効かどうかにかかわらず確認されます（グリッド ダッシュボードに次のメッセージが表示されます： binlogs ボリューム上の空き容量が低下しています。確認してください。）

このような場合、ユーザは手作業で問題を解決する必要があります。

レプリケーションが失敗した場合は、上のセクションで説明したようにし、Web インターフェースを使用して、修正できます。

カスタム カウンタ

MYSQLR64 アプライアンスは mon 端子を介して以下のカスタム カウンタをレポートします。

以下のカウンタは MySql カウンタ グループに属します。

エラー メッセージ

アプライアンスの起動に失敗すると、アプライアンス ログ ファイルまたはグリッド コントローラのシステム ログのいずれかに以下のメッセージが表示されることがあります。

さらに、アプライアンスが実行されている間、以下のエラーがグリッド ダッシュボードに表示される場合があります。

典型的な使用状況

シンプルな 2 層アプリケーション（レプリケーションなし）

以下の図は、2 層 Web アプリケーションでの MYSQLR64 アプライアンスの標準的な使い方を示しています。

使用するアプライアンス：

• user - 入力ゲートウェイ
• web - Web サーバ
• db - MYSQLR64 データベース アプライアンス
• logs - ログ ファイルを格納するための NAS アプライアンス
• content - Web サーバ コンテンツを格納するための NAS アプライアンス
• admin - ログ ファイルを表示するための入力ゲートウェイ
• mon - MON アプライアンス

クライアント リクエストがユーザ ゲートウェイに到達します。 ゲートウェイが Web サーバにリクエストを転送し、この Web サーバがリクエストを提供します。 Web 上のスクリプト（Perl や PHP など）が永続データにアクセスする必要がある場合、Web サーバの out 端子を介して、db アプライアンスを使用します。 db アプライアンスはログによってエクスポーズされた共有のルート ディレクトリ内にログ ファイルを格納するように設定されています。

管理者は、ブラウザを使用して admin ゲートウェイに接続して、mysql または Web サーバのログ ファイルを表示します。 admin ゲートウェイは logs NAS アプライアンスにリクエストを転送します。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

注： データ ボリュームも、logs、content および mon アプライアンスと同様に db アプライアンス上で設定する必要があります。 ここで使用できるアプリケーション ボリュームを作成するには、「グリッド ユーザ ガイド」を参照してください。

拡張性のある 2 層のアプリケーション（レプリケーションなし）

以下の図は、複数の、負荷分散 Web サーバ間の状態およびデータを共有するために、データベースが使用される、2 層 Web アプリケーションでの MYSQLR64 アプライアンスの標準的な使い方を示しています。 さらに、この例には、管理者がデータベースにログインしてメンテナンスできるメンテナンス用の個別の入力および管理者が mysql エラー ログにログインして表示することができる入力があります。

使用するアプライアンス：

• user - ユーザ リクエスト用の入力ゲートウェイ
• web_lb - ユーザ リクエスト用の Web ロード バランサ
• web1、web2 - アクティブなコンテンツ（CGI スクリプトなど）を備えた Web サーバ
• db - データベース
• logs - データベースと Web サーバのエラー ログ ファイル用のストレージおよびそれらへのアクセス
• content - Web サーバ コンテンツ用のストレージ
• maint - メンテナンス アクセス用の入力ゲートウェイ
• admin - 管理者によって使用される汎用 Linux5 サーバ
• gway - 管理者のインターネットへのアクセス用のネットワーク ゲートウェイ
• mon - MON アプライアンス

クライアント リクエストは user ゲートウェイ上に着信します。 このゲートウェイは web_lb ロード バランサにリクエストを転送し、ロード バランサは web1 と web2 のいずれかの Web サーバにリクエストを伝えます。 Web サーバは db データベースにアクセスします。

db データベースおよび web1、web2 サーバは log 端子を介してログ アプライアンスにそれらのログ ファイルを書き込みます。 さらに、管理者は maint ゲートウェイを介して logs アプライアンスにログインして、ログ ファイルを表示できます。

また、管理者は SSH 経由で maint ゲートウェイを介して、admin サーバにログインできます（公開キーと秘密キーを設定する必要があります）。 admin サーバから、管理者は、統計またはデータベース スキーマの変更のために db データベースにアクセスできます。 admin サーバは、たとえば、より新しいバージョンのライブラリやデータベース スキーマをダウンロードするために、gway ゲートウェイを介してインターネットにアクセスできます。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

注：

• データ ボリュームも、db、logs、content および mon アプライアンス上に設定する必要があります。

maint、admin、gway、mon および log アプライアンスは 2 層アプリケーションの操作に必要ありません。 admin サーバが存在する場合、admin サーバにデータベースのスクラブ、電子メールの送信などのためのクローン ジョブがある場合があります。

マスタ/スレーブ レプリケーションを使用する N 層アプリケーション（バックアップに適している）

以下の図は、データベースがスレーブ サーバにレプリケートされる Web アプリケーションでの MYSQL アプライアンスの標準的な使い方を示しています。 スレーブ サーバを使用して、マスタ サーバを停止せずに、データの一貫したバックアップを作成できるため、アプリケーションのダウンタイムをゼロにすることができます。

使用するアプライアンス：

• user - ユーザ リクエスト用の入力ゲートウェイ
• admin - MYSQLR64 アプライアンスへのログ ファイル アクセスおよび Web アクセス用の入力ゲートウェイ
• sw - 各 MYSQLR64 アプライアンスに分割された HTTP トラフィック
• web_lb - ユーザ リクエスト用の Web ロード バランサ
• web1、web2 - アクティブなコンテンツ（CGI スクリプトなど）がある Web サーバ
• master - マスタに設定された MYSQLR64
• slave - スレーブに設定された MYSQLR64
• content - Web サーバ コンテンツ用のストレージ
• logs - データベースおよび Web サーバ ログ ファイル用のストレージ
• mon - MON アプライアンス

クライアント リクエストは user ゲートウェイ上に着信します。 このゲートウェイは web_lb ロード バランサにリクエストを転送し、ロード バランサは web1 と web2 のいずれかの Web サーバにリクエストを伝えます。 Web サーバは master データベースにアクセスします。

スレーブ アプライアンスはマスタ アプライアンスに接続され、そのデータをレプリケートします。 スレーブは、いつでも停止して、マスタ アプライアンスのおよびその他のアプリケーションのパフォーマンスを妨げることなく、SQL データまたは重いアナリティクスの一貫したバックアップを実行することができます。

マスタとスレーブへの Web アクセスはポート 8080 と 8081 上の admin ゲートウェイ経由で利用可能です。

マスタ、スレーブ、web1 および web2 アプライアンスはログによってエクスポーズされた共有のルート ディレクトリ内にログ ファイルを格納するように設定されています。 さらに、管理者は admin ゲートウェイを介してログ ファイルを表示することができます。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

master

slave

注：

• データ ボリュームは、logs、content および mon アプライアンス上に設定する必要があります。
• data および binlogs ボリュームはマスタとスレーブの両方に設定する必要があります。 これらのボリュームは、data と logs の両方を処理するために十分な容量を持つ必要があります。
• 各アプライアンスは自身のボリュームを使用する必要があります（アプライアンス間で共有できません）。

admin、mon および log アプライアンスはレプリケーションの操作に必要ではありません。

マスタ/マスタ レプリケーションを使用する N 層アプリケーション（負荷分散に適している）

以下の図は、マスタ/マスタ レプリケーション シナリオで 2 台のサーバにデータベースがレプリケートされる Web アプリケーションでの MYSQLR64 アプライアンスの標準的な使い方を示しています。 この使用例では、アプリケーションは負荷分散用の操作中に WEB および MYSQLR64 サーバの両方を使用します。 また、WEB/MYSQLR64 インスタンスのうちの 1 つが失敗する場合、別の WEB/MYSQLR64 インスタンスを使用して、アプリケーションのダウンタイムを防ぐことができます。

使用するアプライアンス：

• user - ユーザ リクエスト用の入力ゲートウェイ
• admin - ログ ファイルにアクセスするための入力ゲートウェイ
• sw - 各 MYSQLR64 アプライアンスに分割された HTTP トラフィック
• web_lb - ユーザ リクエスト用の Web ロード バランサ
• web1、web2 - アクティブなコンテンツ（CGI スクリプトなど）がある Web サーバ
• db1 および db2 - 同時にマスタとスレーブの両方になるように設定できる MYSQLR64 アプライアンス
• content - Web サーバ コンテンツ用のストレージ
• logs - データベースおよび Web サーバ ログ ファイル用のストレージ
• mon - MON アプライアンス

クライアント リクエストは user ゲートウェイ上に着信します。 このゲートウェイは web_lb ロード バランサにリクエストを転送し、ロード バランサは web1 と web2 のいずれかの Web サーバにリクエストを伝えます。 web1 は db1 データベース アプライアンスを使用し、web2 は db2 データベース アプライアンスを使用します。 db1 と db2 は Web サーバがデータベースに実行する更新をレプリケートするために接続されます。 重複したエントリが発生しないように、MYSQLR64 アプライアンスはそれぞれ、auto_increment 列にオフセット（server_id と同じ）を使用します。

db1 と db2 への Web アクセスはポート 8080 と 8081 上の admin ゲートウェイ経由で利用可能です。

db1、db2、web1 および web2 アプライアンスはログによってエクスポーズされた共有のルート ディレクトリ内にログ ファイルを格納するように設定されています。 さらに、管理者は admin ゲートウェイを介してログ ファイルを表示することができます。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

db1

db2

注：

• データ ボリュームは、logs、content および mon アプライアンス上に設定する必要があります。
• data および binlogs ボリュームは db1 と db2 の両方に設定する必要があります。 各アプライアンスは自身のボリュームを使用する必要があります（アプライアンス間で共有できません）。
• マスタ/マスタ レプリケーションを実行する場合、空のデータ ボリュームで開始する必要があります。

admin、mon および log アプライアンスはレプリケーションの操作に必要ではありません。

複数ノード マスタ/マスタ レプリケーションを使用する N 層アプリケーション（負荷分散に適している）

以下の図は、マスタ/マスタ レプリケーション シナリオで 4 台のサーバにデータベースがレプリケートされる Web アプリケーションでの MYSQLR64 アプライアンスの標準的な使い方を示しています。 この使用例では、アプリケーションは負荷分散用の操作中にすべての WEB および MYSQLR64 サーバを使用します。 また、WEB/MYSQLR64 インスタンスのうちの 1 つが失敗する場合、別の WEB/MYSQLR64 インスタンスを使用して、アプリケーションのダウンタイムを防ぐことができます（MYSQLR64 は、障害に対応しません）。

使用するアプライアンス：

• user - ユーザ リクエスト用の入力ゲートウェイ
• admin - ログ ファイルにアクセスするための入力ゲートウェイ
• sw - 各 MYSQLR64 アプライアンスに分割された HTTP トラフィック
• web_lb - ユーザ リクエスト用の Web ロード バランサ
• web1、web2、web3、web4 - アクティブなコンテンツ（CGI スクリプトなど）を備えた Web サーバ
• db1、db2、db3、db4 - 同時にマスタとスレーブの両方になるように設定できる MYSQLR64
• content - データベース エラー ログ ファイル、Web コンテンツおよび Web ログ用のストレージ
• logs - データベースおよび Web サーバ ログ ファイル用のストレージ
• mon - MON アプライアンス

クライアント リクエストは user ゲートウェイ上に着信します。 ゲートウェイは Web ロード バランサにリクエストを転送し、Web ロード バランサは web1、web2、web3 および web4 のいずれかの Web サーバにリクエストを伝えます。 Web サーバはそれぞれそれ自身のデータベース アプライアンスを使用します。 データベース アプライアンスはすべて Web サーバがデータベースに実行する更新をレプリケートするために循環的に接続されます。 したがって、たとえば db1 への更新は db2、db3 および db4 にレプリケートされます。 重複したエントリが発生しないように、MYSQLR64 アプライアンスはそれぞれ、auto_increment 列にオフセット（server_id と同じ）を使用します。

db1、db2、db3、db4 への Web アクセスはポート 8080、8081、8082 および 8083 上の admin ゲートウェイ経由で利用可能です。

db1、db2、web1 および web2 アプライアンスはログによってエクスポーズされた共有のルート ディレクトリ内にログ ファイルを格納するように設定されています。 さらに、管理者は admin ゲートウェイを介してログ ファイルを表示することができます。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

db1

db2

db3

db4

注：

• データ ボリュームは、logs、content および mon アプライアンス上に設定する必要があります。
• data および binlogs ボリュームもすべての db アプライアンス上に設定する必要があります。 各アプライアンスは自身のボリュームを使用する必要があります（アプライアンス間で共有できません）。
• マルチ マスタ レプリケーションを実行する場合、空のデータ ボリュームで開始する必要があります。

admin、mon および log アプライアンスはレプリケーションの操作に必要ではありません。

異なる機能上で作動する N 層アプリケーション（負荷分散とフェールオーバに最適）

以下の図は、複数の施設で動作する Web アプリケーションでの MYSQLR64 アプライアンスの標準的な使い方を示しています。 このセットアップで、2 つ以上の同一のアプリケーションをマスタ/マスタ設定のすべてのアプリケーションにデータベースをレプリケートして、さまざまな組織で実行することができます。 これは次の 2 つの場合に役立ちます。

• 地理的な負荷分散 - 2 つ（またはそれ以上）のアプリケーションをユーザが応答時間を改善するために（負荷分散は DNS によって行われます）、ユーザの地理的地域に最も近い場所にあるアプリケーションを使用できるように設定する場合。
• フェールオーバ - 2 つ（またはそれ以上）のアプリケーションを、あるアプリケーションが動作する施設全体がダウンした場合（またはアプリケーション自体がダウンした場合）に、ダウンタイムを防ぐために他のアプリケーションを使用できるように設定する場合。

マスタ アプリケーション

スレーブ アプリケーション

使用するアプライアンス：

• user - ユーザ リクエスト用の入力ゲートウェイ
• admin - ログ ファイルにアクセスするための入力ゲートウェイ
• sw - admin からマスタまたはスレーブ上の ui にポート 8080 をリダイレクトする
• vpn - リモート アプリケーションが master=/=slave アプライアンスに接続して、データベースをレプリケートするための入力
• web_lb - ユーザ リクエスト用の Web ロード バランサ
• web1、web2 - アクティブなコンテンツ（CGI スクリプトなど）がある Web サーバ
• master - マスタに設定された MYSQLR64
• slave - スレーブに設定された MYSQLR64
• content - データベース エラー ログ ファイル、Web コンテンツおよび Web ログ用のストレージ
• logs - データベース エラー ログ ファイル用のストレージ

クライアント リクエストは user ゲートウェイに到達します。 このゲートウェイは web_lb ロード バランサにリクエストを転送し、ロード バランサは web1 と web2 のいずれかの Web サーバにリクエストを伝えます。 Web サーバは master データベースにアクセスします。 マスタ アプライアンスは、データベースをレプリケートするためにリモート（スレーブ）アプリケーションに接続します（唯一の違いはスレーブの server_id とネットワーク設定です）。 リモート アプリケーションは、リモート アプリケーションの vpn ゲートウェイからのみ接続をできるように設定されている vpn ゲートウェイを介してマスタ アプライアンスに接続します。 2 つのアプリケーション内のマスタ アプライアンスとスレーブ アプライアンスはマスタ/マスタ設定で実行されているため、常に同一のデータを使用します。

プロパティ設定の例（リストに表示されていないプロパティはデフォルト値のままにしてください）：

マスタとスレーブへの Web アクセスはポート 8080 上の admin ゲートウェイ経由で利用可能です。

master

master vpn

slave

slave vpn

リモート アプリケーションは正確なコピーです。唯一の違いは、user、admin および vpn アプライアンスのネットワーク設定、vpn アプライアンスと master=/=slave の間の接続および master=/=slave アプライアンスの server_id（一意であること）です。

別のアプライアンスからのデータベースのマイグレート

MYSQLR から MYSQLR64 （またはその逆）にマイグレートする必要がある場合は、データ破損の原因になる可能性があるので、64 ビット アプライアンス上で 32 ビット アプライアンス（またはその逆）からのボリュームを単に使用しないでください。 この場合に推奨される方法は、古いアプライアンス上のデータベースをダンプし、ダンプされたファイルを新しいアプライアンスに転送した後で、新しいアプライアンスにデータベースをインポートすることです。

さらに古いデータベース アプライアンス（MYSQL、MYSQL5、MYSQL64）または CA 3Tera AppLogic アプライアンス上で実行されない mysql データベースをマイグレートする場合、同じ手順が使用できます。

データベースをマイグレートする方法

• （オプション）古いデータベースにアクセスしないようにします。これはオプションです。ダンプ中のデータベースが変更されないようにすることのみに役立ちます。 この場合の 1 つの方法として、その入力端子上で何も接続されていないアプライアンスを起動します。
• 古いアプライアンス上のデータベースをすべてダンプします。 これを行う前に、データ ボリューム上に十分なスペースがあることを確認してください（十分なスペースがない場合は、データ ボリュームのサイズをいつでも変更できます）。 これを行うにはアプライアンスを起動します。アプライアンスにログインし、以下のコマンドを実行します。
  • mysqldump --all-databases --lock-all-tables | gzip > /mnt/data/my_dump.sql.gz
• アプリケーションを停止します。
• 新しいアプライアンス（ext3- スナップショット）用のデータベースを格納する新しいアプリケーション ボリュームを作成します。 データベース ダンプ ファイル（/mnt/データ/my_dump.sql.gz）およびデータベース自体を保持するのに十分なボリュームがあることを確認してください。
• 新しく作成されたボリュームにデータベース ダンプ ファイルを転送します（以下に示すのは、外部インターネット アクセス用にセットアップされた 2 つのファイラを使用してデータベースをコピーする 1 つの方法の例です。この方法が設定に適していない場合は、scp を使用して、グリッドから外部サーバにデータベースをコピーし、宛先ボリュームに戻ることもできます）。
  • 2 つのファイラ（各ボリュームに 1 つ）を使用して、各ボリュームを個別に管理します。vol 管理コマンドを使用します。 vol 管理コマンド ラインでは、必ず外部 IP 情報を渡して、それぞれのファイラが互いにアクセスし、2 つのボリューム間でデータベースをコピーできるようにしてください。 外部ネットワーク設定の指定方法の詳細については、vol 管理ヘルプを参照してください。
  • ソース ボリューム用のファイラで、以下を実行します。cat /etc/ssh/ssh_host_rsa_key.pub >> /root/.ssh/authorized_keys。
  • 宛先ボリューム用のファイラで、以下を実行します。scp -pr -i /etc/ssh/ssh_host_rsa_key IP_address_to_source_filer:/mnt/vol/my_dump.sql.gz /mnt/vol/。
  • データベースがコピーされた後は、両方のファイラを終了できます。
• アプリケーションを編集し、MYSQLR/MYSQLR64 の新規インスタンスを追加して、パラメータ化します。さらに、接続を行って、新規インスタンスに作成された新しいボリュームを割り当てます。 現時点では、古い MYSQLR/MYSQLR64 インスタンスをアプリケーションから削除できます（ただし、データベースが新規インスタンスに正しく転送されたことを確認できるまで、バックアップの目的で維持しておくことも可能です）。
• データベースをインポートします。新しいアプライアンスを起動してログインし、以下のコマンドを実行します。
  • zcat /mnt/data/my_dump.sql.gz | mysql

データベースが転送されて、アプライアンスが使用できる状態になります。

注

以下の点に留意してください。

• MYSQLR64 のパフォーマンスは、デフォルトで使用される MyISAM ストレージ エンジン用に最適化されています。 Innodb 用にパフォーマンスを強化するか、単にアプリケーション用の MYSQL サービスを調整する場合は、「カスタム設定」セクションで、既存の設定に設定パラメータを追加する方法の詳細を参照してください。 この機能は MYSQLR64 1.6.1 以降で利用可能です。
• MYSQLR64 では、非同期レプリケーション（同期レプリケーションは MySQL によって未サポート）のみを使用します。
• MYSQLR64 は、2 分以内でレプリケーション エラーを検出し、グリッドのダッシュボード上にメッセージをポストしてユーザに通知します。 その後、ユーザは、MYSQLR64 GUI を使用して問題を修正できます（自動回復は、MYSQLR64 によって提供されません）。
• MYSQLR64 を起動すると、chmod が mysql ログ ファイルの所有者の変更に失敗したというメッセージがアプライアンス ログ ファイルに書き込まれます。 これは予期されていることで、MYSQLR64 アプライアンスの操作に影響しません。
• 単一のレプリケーションでの MYSQLR64 アプライアンスの理論的な最大数は 10 です。 データが循環的にレプリケートされるため、MYSQLR64 アプライアンスの数を増加させると、スレーブがそのデータベースを更新するのにかかる時間が長くなります。 レプリケーションでのアプライアンスの実際の最大数は、ユーザのアプリケーション、負荷およびニーズに応じて低くなる場合があります（データ バックアップなどのシナリオでは、スレーブの即時更新が重要でないこともあります）。

重要： データベースのユーザを作成するときは、接続元のホスト上の制限なしですべてのユーザが作成されていることを確認してください。 例：

mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

• ボリューム要件
  • データ ボリューム サイズは 100MB 以上にする必要があります。現在、InnoDB エンジンは有効です。また、データ ボリューム上で約 22MB を占有しています。 このバージョンでは、データ ストレージ用の InnoDB を使用しない場合でもこれを無効にできません。
  • LVM ボリュームを構築するために使用されるため、データ ボリュームはファイル システムに合わせてフォーマットしないでください（ボリュームはフォーマットしません）。 任意のファイル システム（古い MYSQL アプライアンスから取得したファイルなど）に合わせてフォーマットされたボリュームを使用すると、アプライアンスはファイルの削除を防止できなくなります。
  • データ ボリュームのスペースの 20% は、レプリケーションの開始または修正用に割り当てられ、残りの 80% はデータベース ストレージ用に使用されます。
  • レプリケーション シナリオ内で MYSQLR64 を、マスタ、スレーブまたは master_ および _slave として使用するときは、binlogs ボリュームを提供する必要があります。 バイナリ ログは 100MB でローテートされ、ローテート後 2 日間維持されてから削除されます。 アプライアンスがスレーブとしても実行される場合は、リレー ログも binlogs ボリュームに格納されます。マスタ/マスタ レプリケーションを実行するには、少なくとも 500MB の binlogs スペースが必要です。 実際のサイズは、実行される MySQL の更新/挿入クエリの集中度によって異なります。アプリケーションの通常動作では少ない GB binlogs ボリュームで十分です。
• MYSQLR64 に接続されたアプライアンスには、専用のデータベースとテーブルが存在しない場合に作成する役割があります。 または、手動でデータ ボリューム上に初期データベースをコピーできます。
• MYSQLR64 の in 入力端子に接続されたアプライアンスまたはサーバで MySQL サーバにアクセスしてリクエストをサブミットするには、MySQL クライアント ライブラリが必要です。 アプライアンス カタログで提供されるすべての仮想サーバは、汎用 LINUX サーバを含めて、MySQL クライアント ライブラリがインストールされている必要があります。
• 参照情報：
  • http://www.mysql.com --MySQL の Web サイト

http://dev.mysql.com/doc/refman/5.0/en/index.html --MySQL 5.0 ドキュメント

アプライアンス内で使用されるサードパーティ オープンソース ソフトウェア

MYSQLR64 は、ベース クラス LUX64 で使用されるサードパーティのオープン ソース パッケージに加えて、以下のサードパーティのオープン ソース パッケージを使用します。

MYSQLR トラブルシューティング

MYSQLR アプライアンスが再起時にフリーズする

MYSQLR 1.6.2 から、ルート データベース アカウントのパスワードを設定および変更できます。 ただし、MSYQLR アプライアンスには異なるホスト名を備えたいくつかのルート アカウントがあります。 パスワードを設定または変更する場合は、常に root@% アカウントを使用する必要があります。 root@% アカウントは MYSQLR の in 端子に接続されるアプライアンスが認証するアカウントです。 他のルート アカウントはローカル ユーザからのみ使用されるため、ルート アカウントにはパスワードを決して設定しないでください。そうすると MYSQLR アプライアンスの起動が失敗します。

注： root@localhost アカウントにパスワードを与えなくても、セキュリティの問題とはなりません。このアカウントはアプライアンス上のローカル ユーザによってのみ使用可能であり、アプライアンスにアクセスできるユーザは誰でもパスワード変更ができるからです。

ルート データベース パスワードを変更した後に開始しない MYSQLR アプライアンスの回復

データベースのルート パスワード変更のために開始しないアプライアンスを回復するには、以下の手順を実行します。

1. アプライアンスまたはアプリケーションをデバッグ モードで開始します。

   アプライアンス開始コマンド

   comp start main.MYSQLR --debug 
   

   アプリケーション開始コマンド

   app start --debug 
   

   アプライアンスを開始した数秒後、アプライアンスにログインすることができます。 アプライアンスのタイムアウトを待つ必要はありません。

2. SSH を介してアプライアンスへログインし、以下のコマンドを実行します。

   mysql -p -e "update mysql.user set Password='' where User='root'" 
   mysqladmin -p flush-privileges 
   mysql -e 'update mysql.user set password=PASSWORD("NEWPASSWORD") where User="root" and Host="%"' 
   mysqladmin flush-privileges
   

アプライアンスを再起動して、正常なブート、およびユーザ ルートの「in」端子への mysql 接続がパスワードを必要とすることを確認します。