データベース・ミラーリングには別途ライセンスが必要です。別途ライセンスが必要なコンポーネントを参照してください。
「データベース・ミラーリング」とは、異なるコンピュータ上で実行されている 2 つまたは 3 つのデータベース・サーバが連携してデータベースやトランザクション・ログ・ファイルのコピーを保持する構成です。
「プライマリ・サーバ」と「ミラー・サーバ」は、それぞれがデータベース・ファイルとトランザクション・ログ・ファイルのコピーを保持し、「監視サーバ」と呼ばれる第 3 のサーバが、必要に応じて、前記 2 つのサーバのどちらにデータベースの所有権を持たせるかを決定します。監視サーバはデータベースのコピーを保持しません。この 3 種類のデータベース・サーバ (プライマリ、ミラー、監視の各サーバ) による構成は「ミラーリング・システム」と呼ばれ、プライマリ・サーバとミラー・サーバは併せて「稼働サーバ」または「パートナー」と呼ばれます。
クライアントがデータベースにアクセスする場合は、プライマリ・サーバに接続します。データベースに対するあらゆる変更は、プライマリ・サーバ上のトランザクション・ログ・ファイルに記録されます。変更がコミットされると、トランザクション・ログ・ページがミラー・サーバに送信され、データベースのミラー・コピーに適用されます。サーバがミラー・サーバとして動作している間は、そのミラー・サーバにあるデータベースのコピーには読み込み専用モードでのみアクセスできます。ミラー・サーバで実行されているデータベースへの読み込み専用アクセスの設定を参照してください。
プライマリ・サーバがハードウェアやソフトウェアの障害により使用できなくなった場合、ミラー・サーバが監視サーバとネゴシエートしてデータベースの所有権を取得し、プライマリ・サーバのロールを引き受けます。所有権の譲渡、すなわち「ロールの切り替え」を実施するには、ダウンしていない稼働サーバと監視サーバは、ロールの切り替えを行おうとする時点で、ミラーが最新で同期された状態にあることを合意する必要があります。それまで元のプライマリ・サーバに接続されていたクライアントはすべて切断され、コミットされていないトランザクションはすべて失われます。クライアントがデータベースへのアクセスを続行するには、新しいプライマリ・サーバ上のデータベースに接続し直す必要があります。元のプライマリ・サーバは、再び使用可能になると、ミラー・サーバのロールを引き受けます。
データベース・サーバのデータベース・サーバ・メッセージ・ウィンドウには、起動時に、そのサーバが引き受けているロールと起動プロセスの進捗状況を示すステータス・メッセージが表示されます。また、ミラーリング・システムを構成する他の 1 つ以上のサーバが失われたことが原因でデータベースの再起動が必要になった場合、またはロールがミラーからプライマリに変更された場合に、メッセージが表示されます。
ミラーリング・システムを構成するいずれかのサーバでアサーションが失敗すると、そのサーバはデータベース・サーバ・メッセージ・ログにエラーを出力して終了します。これにより、他のサーバに障害発生が通知され、適切なアクションが実行されます。
データベース・ミラーリングにハードウェアやソフトウェアに関する特別な要件はありません。また、各データベース・サーバは、地理的に離れたロケーションで実行されていてかまいません。データベース・ミラーリング・システムを構成するデータベース・サーバでは、ミラーリングされたデータベースもされていないデータベースも実行できます。また、監視サーバは、複数のデータベース・ミラーリング・システムの監視サーバになることができます。
データベース・ミラーリング・システムの各データベースのステータスの詳細は、ステータス情報ファイルに格納されます。ステータス情報ファイルを参照してください。
データベース・ミラーリングは、バックアップとリカバリのプランの代用ではありません。データベースには、バックアップとリカバリの手段を必ず実装してください。データベース・ミラーリングとバックアップとバックアップとデータ・リカバリを参照してください。
データベース・ミラーリングに関連する SQL Anywhere のアップグレードやデータベースの再構築の詳細については、データベース・ミラーリング・システムでの SQL Anywhere ソフトウェアとデータベースのアップグレードを参照してください。
サーバがプライマリ・サーバのロールを引き受けるには、「クォーラム」が必要です。これは、他のサーバの少なくともどちらか 1 つがデータベースの所有に合意していことを意味します。ミラー・サーバが使用できなくなった場合でも、プライマリ・サーバと監視サーバが接続されていれば、プライマリ・サーバは引き続きデータベースへのアクセスを提供します。プライマリ・サーバがクォーラムを失った場合、プライマリ・サーバはデータベースへのアクセスを許可できなくなります。その時点で、プライマリ・サーバは、ミラーリングされているデータベースを停止し、再起動を試行し、クォーラムを再び取得するのを待ってから、データベースをアクセス可能にします。
データベース・ミラーリング・システムが起動されると、データベース・サーバは起動プロセスを開始してクォーラムを形成し、クライアント接続を受け付けます。このプロセスにおける一般的なイベントの流れは次のとおりです。
監視サーバは、サーバ 1 とサーバ 2 を待機します。
サーバ 1 が監視サーバまたはサーバ 2 を探します。
サーバ 1 が監視サーバに接続します。
サーバ 1 は、プライマリ・サーバになるために監視サーバとネゴシエートします。
監視サーバとサーバ 1 は、サーバ 1 がプライマリ・サーバになることで合意します。
サーバ 1 は接続の受け付けを開始します。
サーバ 2 は、サーバ 1 と監視サーバを探します。
サーバ 2 が監視サーバとサーバ 1 に接続します。
サーバ 2 はクォーラムを要求します。しかし、サーバ 1 がプライマリなのでクォーラムを取得できず、サーバ 2 はサーバ 1 からのトランザクションの待機状態に入ります。
サーバ 1 はトランザクションをサーバ 2 に送信します。
データベース・ミラーリングを使用する場合は次のような制限があります。
ネットワーク・データベース・サーバが必要 ミラーリングにはデータベース・サーバ間のネットワーク通信が必要なので、ネットワーク・データベース・サーバ (dbsrv11) を使用する必要があります。パーソナル・サーバは使用できません。
LOAD TABLE 文 ベース・テーブルで LOAD TABLE 文を実行する場合は、文のロギング・レベルとして、WITH ROW LOGGING または WITH CONTENT LOGGING を指定する必要があります。これらの句を指定することで、ロードされたデータをトランザクション・ログに記録して、ミラーリング・データベースにもロードできるようになります。これらの句が指定されていない場合は、エラーがレポートされます。LOAD TABLE 文とLOAD TABLE 文を使用したデータのインポートを参照してください。
フェールオーバとスケジュールされたイベント スケジュールされたイベントのあるデータベースでフェールオーバが発生した場合、イベントの予定開始時刻の前にフェールオーバが完了していれば、スケジュールされたイベントはミラー・サーバで実行されます。完了しなかった場合、該当イベントは次にスケジュールされている時刻にミラー・サーバで実行されます。
トランザクション・ログの制限 データベース・ミラーリングを使用している場合、トランザクション・ログのトランケートは実行できません。これは、トランザクションが失われる可能性があるからです。トランザクション・ログの名前は、必要に応じて何度でも変更できます。古いトランザクション・ログを削除する場合は、不要であることを確認したうえで、イベントのスケジュールを使用して削除できます。たとえば、作成されてから 1 週間が過ぎたトランザクション・ログのコピーを削除する毎日実行されるイベントを作成できます。データベース・ミラーリングとトランザクション・ログ・ファイルを参照してください。
Web サーバはミラーリング・システムに参加できない データベース・ミラーリング・システムに参加している SQL Anywhere データベース・サーバは、Web サーバとしては使用できません。これは、フェールオーバが発生した場合に、データベース・サーバの IP アドレスが変更されるからです。
データベース・ミラーリングを使用する場合、アプリケーションは、ほとんどのケースでミラーリングされていないデータベースに接続している場合と同じように実行できます。ただし、データベース・ミラーリングが関係するアプリケーションを開発するうえで、考慮すべき点がいくつかあります。
データベースに再接続できるクライアントを作成する (たとえば、フェールオーバが発生した場合、ユーザがアプリケーションをシャットダウンして再起動する必要が生じることがあります)。
非同期モードまたは非同期フルページ・モードで実行している場合、フェールオーバが発生してトランザクションがデータベースにコミットされない場合の対処法を決定する必要がある。
ミラー・サーバがデータベースの所有権を引き継ぐ場合は、不完全なトランザクションをロールバックする必要があるが、トランザクションが長いほど、ロールバックに時間がかかる。フェールオーバのリカバリ速度は、クライアントの数とロールバックする必要があるトランザクションの長さに影響されます。リカバリ速度が問題になる場合は、できるだけ短いトランザクションを使用するようアプリケーションを設計してください。
データベース・ミラーリング・システムを使用するための SQL Anywhere のアップグレード (EBF の適用を含む) については、データベース・ミラーリング・システムでの SQL Anywhere ソフトウェアとデータベースのアップグレードを参照してください。
データベース・ミラーリングの利点
監視サーバのロールの概要
データベース・ミラーリングで使用するモードの選択
| Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |