前のトピック: MYSQLR、MYSQLR64 - レプリケーションに適した MySQL データベース アプライアンス

次のトピック: マスタ/マスタ レプリケーションを使用する N 層アプリケーション(負荷分散に適している)


プロパティ

プロパティ名

タイプ

説明

auto_create

整数

データベースが存在しない場合、データベースを作成するべきかどうかを決めます。 有効な値である 1 では、作成され、0 では自動作成が行われません(ボリュームが壊れている場合の不意の上書きを防止)。 0 に設定されていて、データベースがデータ ボリュームに存在しない場合、アプライアンスは、メンテナンス モードで起動されます(アプライアンスは正しく起動されますが、ユーザが問題を確認できるように、MySQL デーモンは開始されません)。 デフォルトは 1 です。

error_log_filename

文字列

ログ ファイルシステムを基準にしたエラー ログ ファイルの名前(たとえば、/mysql_logs/my.log)。 パス内のディレクトリは自動作成されます。 空の場合、エラー ログはデータ ボリューム(/mnt/data/error.log)に書き込まれます。 デフォルト: (空)

error_log_level

文字列

エラー ロギング レベル。 可能な値は、error logs only errors、warn logs both warnings and errors です。 このプロパティは、大文字と小文字を区別しません。 デフォルト: error

timezone

文字列

アプライアンスで使用されるタイムゾーンを指定します。 このプロパティが空の場合、タイムゾーンは変更されず、現状のものが使用されます。 サポートされているタイムゾーンのリストは ここ.

重要:

詳細プロパティ(レプリケーション シナリオ内で使用)

プロパティ名

タイプ

説明

server_id

整数

サーバ ID。 可能な値は 1 ~ 10 です。 レプリケーションを実行するときに、サーバの ID を指定します。 レプリケーションの一部となるすべてのサーバに一意の ID を設定することを保証します。 デフォルト: 1

rpl_mode

文字列

レプリケーション モード。 選択可能な値は、none(レプリケーションなし)、master、slave、および master_and_slave (サーバが同時にマスタとスレーブになるマルチ マスタ レプリケーションの場合)です。 デフォルト: none

web_pwd

文字列

Web インターフェースへの認証用のパスワード。 このパラメータはオプションです。 設定されている場合、アプライアンスの http サーバが起動され、Web インターフェースは、ui 端子およびCA AppLogic エディタの[ログイン(Web)]オプションによってアクセスできるデフォルト インターフェースの両方にエクスポーズされます。 デフォルト: (空)

カスタム設定

この機能は 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 AppLogic エディタ内の[ログイン(Web)]オプションによるデフォルト インターフェースの両方でアクセスできる Web インターフェースを提供します。 Web インターフェースを使用するには HTTP 認証が必要です。 ユーザ名をブランクのままにして、パスワードとして web_pwd の値を使用します。 このインターフェースには以下の機能があります。

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

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

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

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

CA 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 の最初からのバイナリ ログを読み取ります。
  8. すべての MYSQLR64 アプライアンスの Web インターフェースの上へログインし、レプリケーション ステータスを検証します。レプリケーションは 5 分以内にすべてのアプライアンスで実行されます。
マスタ/スレーブ設定内のレプリケーションの修復

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

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

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

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

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

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

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

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

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

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

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

カスタム カウンタ

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

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

カウンタ名

説明

Aborted Clients

サーバによって中断されたクライアントの数

Aborted Connections

サーバによって中断された接続の数

Bytes Received

受信したバイト数

Bytes Sent

送信したバイト数

Total Connections

接続数

Questions

呼び出しの合計数

Slow Queries

遅いクエリの数

Threads Created

作成されたスレッドの数

Threads Connected

接続されたスレッドの数

Threads Running

実行中のスレッドの数

Max Used Connections

使用された接続の最大数

Open Files

開いているファイルの数

Admin Commands

admin コマンドの数

Alter Table Commands

alter table テーブル コマンドの数

Analyze Commands

analyze コマンドの数

Change DB Commands

Change DB コマンドの数

Change Master Commands

Change Master コマンドの数

Check Commands

check コマンドの数

Commit Commands

commit コマンドの数

Create DB Commands

create DB コマンドの数

Create Function Commands

create function コマンドの数

Create Index Commands

create index コマンドの数

Create Table Commands

create table コマンドの数

Delete Commands

delete コマンドの数

Drop DB Commands

drop DB コマンドの数

Drop Function Commands

drop function コマンドの数

Drop Index Commands

drop index コマンドの数

Drop Table Commands

drop table コマンドの数

Flush Commands

flush コマンドの数

Grant Commands

grant コマンドの数

Insert Commands

insert コマンドの数

Insert Select Commands

insert select コマンドの数

Kill Commands

kill コマンドの数

Load Commands

load コマンドの数

Lock Tables Commands

lock tables コマンドの数

Optimize Commands

optimize コマンドの数

Purge Commands

purge コマンドの数

Rename Table Commands

rename table コマンドの数

Repair Commands

repair コマンドの数

Replace Commands

replace コマンドの数

Replace Select Commands

replace select コマンドの数

Reset Commands

reset コマンドの数

Revoke Commands

revoke コマンドの数

Rollback Commands

rollback コマンドの数

Select Commands

select コマンドの数

Set Option Commands

set option コマンドの数

Truncate Commands

truncate コマンドの数

Unlock Tables Commands

unlock tables コマンドの数

Update Commands

update コマンドの数

エラー メッセージ

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

エラー メッセージ

説明

タイムゾーンを設定できませんでした

timezone プロパティで設定されるアプライアンスのタイム ゾーンを設定できませんでした。

アプライアンスは[$rpl_mode]レプリケーション モードで実行されていますが、binlogs ボリュームが見つかりません。

アプライアンスはマスタ、スレーブまたは master_and_slave のいずれかとして実行されるように設定されていますが、binlogs ボリュームは与えられていません。

アプライアンスは[$rpl_mode]レプリケーション モードで実行されていますが、「rout」端子が接続されていません。

アプライアンスはマスタ、スレーブまたは master_and_slave のいずれかとして実行されるように設定されていますが、「rout」端子が接続されていません。

「rout」端子が接続されていますが、[rpl_mode]プロパティは「none」に設定されています。 [rpl_mode]プロパティを介してレプリケーションを形成するか、または「rout」端子を切断してください。

rout 端子が接続されていますが、[rpl_mode]プロパティが「none」に設定されています。 [rpl_mode]プロパティを介してレプリケーションを設定するか、または「rout」端子を切断してください。

接続されない error_log_filename セットおよび log 端子のために mysql を開始できませんでした。

error_log_filename プロパティが設定されていますが、log 端子が接続されていません。

log 端子を介して共有をマウントできませんでした。

アプライアンスは log 端子にログを書き込むように設定されていましたが、log 端子に共有をマウントできませんでした。

log 端子による共有は書き込み可能ではありません。

log 端子上の共有は書き込み可能ではありません。

log 端子上で logdir [$logdir]を作成できませんでした。

log 端子上で logdir [$logdir]を作成できませんでした。

logdir [$logdir]は書き込み可能ではありません。

log 端子上の logdir [$logdir]は書き込み可能ではありません。

ログ ファイル[$error_log]は書き込み可能ではありません。

log 端子上のログ ファイル[$error_log]は書き込み可能ではありません。

データベースの作成に失敗しました。

アプライアンスはデータベースなしで起動し、mysql データベースをインストールできませんでした。

レプリケーションを設定できませんでした。

アプライアンスはレプリケーションを設定できませんでした。

mysql を起動できませんでした。

MySQL デーモンを起動できませんでした。

mysql データベースでの権限が不十分です。

「root'@'%」権限が不十分か、または、もしレプリケーション モードに使用されている場合、「replication_user'@'%」に MySQL レプリケーションを実行するのに十分な権限がありません。

Web インターフェースを起動できませんでした。

Web インターフェースを起動できませんでした。

データ ボリューム サイズは 100Mb 以上にする必要があります。

次にデータ ボリュームを、100 メガバイトより大きくする必要があります。 ボリューム要件に関する注意事項を参照してください。

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

エラー メッセージ

説明

データ ボリューム上の空き容量が少なくなっています。確認してください。

データ ボリューム上の空き容量が 20% 未満です。

マスタ サーバのレプリケーションは実行していません。確認してください。

マスタ サーバのレプリケーションが実行されていません。

マスタのバックグラウンドでのスレーブのレプリケーションの回数が多すぎます。確認してください。

マスタのバックグラウンドでのスレーブのレプリケーションの回数が多すぎます。

binlogs ボリューム上の空き容量が少なくなっています。確認してください。

binlogs ボリューム上の空き容量は 20% 未満です。

シンプルな 2 層アプリケーション(レプリケーションなし)

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

シンプルな 2 層アプリケーション(レプリケーションなし)

使用中のアプライアンス:

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

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

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

プロパティ名

ノート

auto_create

1

ボリュームが空の場合は、データベースを作成します。

error_log_filename

db.error

logs データ ボリューム上に格納されるエラー ログ ファイルの名前。

error_log_level

error

エラー ログ レベル

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

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

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

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

使用中のアプライアンス:

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

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

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

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

プロパティ名

ノート

auto_create

1

ボリュームが空の場合は、データベースを作成します。

error_log_filename

db.error

logs データ ボリューム上に格納されるエラー ログ ファイルの名前。

error_log_level

error

エラー ログ レベル

注:

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

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

マスタ/スレーブ レプリケーションを使用する N 層アプリケーション(負荷分散を実行するのに適している)

使用中のアプライアンス:

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

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

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

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

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

master

プロパティ名

ノート

auto_create

1

ボリュームが空の場合は、データベースを作成します。

error_log_filename

master-db.error

logs データ ボリューム上に格納されるエラー ログ ファイルの名前。

error_log_level

error

エラー ログ レベル

server_id

1

マスタ サーバ(1 である必要はないが、スレーブ上の server_id とは異なること)

rpl_mode

master

レプリケーションを作成するめにバイナリ ログを書き込みます。

slave

プロパティ名

ノート

auto_create

1

ボリュームが空の場合は、データベースを作成します。

error_log_filename

slave-db.error

logs データ ボリューム上に格納されるエラー ログ ファイルの名前。

error_log_level

error

エラー ログ レベル

server_id

2

スレーブ サーバ(2 である必要はないが、マスタ上の server_id とは異なること)

rpl_mode

slave

マスタに接続します

注: