参照情報 › アプライアンス カタログ リファレンス ガイド › システム カタログ › データベース アプライアンス › MYSQLR、MYSQLR64 - レプリケーションに適した MySQL データベース アプライアンス › 異なる機能上で作動する N 層アプリケーション（負荷分散とフェールオーバに最適）

異なる機能上で作動する 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 へのマイグレート（またはその逆）

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

さらに古いデータベース アプライアンス（MYSQL、MYSQL5、MYSQL64）または CA 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
   

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