Mirroring 101
Cachéミラーリングは、CachéおよびEnsembleベースのアプリケーションに適した信頼性が高く、安価で実装しやすい高可用性および災害復旧ソリューションです。 ミラーリングは幅広い計画停止シナリオや計画外停止シナリオで自動フェイルオーバーを提供するもので、通常はアプリケーションの回復時間を数秒に抑制します。 論理的にデータが複製されるため、単一障害点およびデータ破損の原因となるストレージが排除されます。 ほとんど、またはダウンタイムなしでアップグレードを実行できます。
ただし、Cachéミラーの展開にはかなり大がかりな計画が必要であり、さまざまな手順が要求されます。 また、他の重要なインフラストラクチャコンポーネントと同様に、運用中のミラーには継続的な監視とメンテナンスが必要とされます。
この記事はよくある質問のリスト、あるいはミラーリングの理解と評価、ミラーの計画、ミラーの設定、ミラーの管理という簡単な一連のガイドとして利用することができます。 それぞれの回答には、各トピックの詳細なディスカッションへのリンクと各タスクの段階的手順へのリンクが含まれています。
ミラーを導入する計画を始める準備ができたら、まずはCaché高可用性ガイドの「ミラーリング」の章のミラーリングのアーキテクチャと計画セクションから必ず読み始めるようにしてください。
よくある質問
|
データベースのコピーは、実際の本番データベースとどのように同期されますか？ |
|
|
フェイルオーバー時にアプリケーションの接続を新しいプライマリにリダイレクトするためのオプションにはどのようなものがありますか？ |
|
|
ミラーデータベースを作成するには？ 既存のデータベースをミラーに追加するには？ フェールオーバーした後、ECPにアプリケーションサーバーの接続をリダイレクトさせるには？ |
|
ミラーリングの理解と評価
ミラーリングのメリットとは？
CachéおよびEnsembleベースのアプリケーションでは、主にフェールオーバークラスター 、仮想化HA 、およびCachéミラーリングの3つの手法で高可用性を確保しています。 最初の2つの最大の欠点は、共有ストレージに依存していることです。そのため、ストレージの障害が発生すると甚大な被害が発生します。これは必要に応じてストレージレベルで冗長性を確保することにより改善できますが、ある種のデータ破損も引き続き発生する可能性があります。 さらに、ソフトウェアのアップグレードにはかなりのダウンタイムが必要であり、多くの障害ではアプリケーションの復旧に数分程度の時間を要する可能性があります。
ミラーリングでは2つの物理的に独立したシステムを使用して別々のストレージに論理データを複製することで、共有ストレージの問題を回避しています。また、アップグレードに必要とされるダウンタイムはゼロまたは最小限に抑えられているため、アプリケーションの復旧時間は通常数秒となります。 また、この手法では本番データセンターから適切な距離に災害復旧サイトを配置し、ミラーリングによる信頼性の高い堅牢な災害復旧機能を提供することができます。
ミラーリングの主な制限事項として、データベース自体のみを複製することが挙げられます。そのため、アプリケーションが必要とする外部ファイルには追加のソリューションが必要であり、現状はセキュリティと構成管理が分散化されています。
以下の情報源では、これらのHA手法の詳細な分析と比較、およびミラーリングのメリットに関する詳細な情報を提供しています。
- システムフェールオーバー戦略（Caché高可用性ガイド）
- 高可用性手法（ホワイトペーパー）
- 事業継続性を実現する高可用性（ビデオ）
- Cachéミラーリング：高可用性の冒険（ビデオ）
- ミラーリング：スループットの設計（オンライン学習）
- InterSystems Caché：データベースミラーリング：概要（ホワイトペーパー）
- HealthShare：ミラーリングによる高可用性の実現（オンライン学習）
仮想化環境にミラーを導入できますか？
ミラーリングはよく仮想化環境に導入されています。 ミラーによって自動フェールオーバーを介した計画停止や計画外停止への即時対応が実現するいっぽうで、仮想化HAソフトウェアが計画外のマシンやOSの停止が発生した後にミラーメンバーをホストしている仮想マシンを自動的に再起動します。 そのため、障害が発生したメンバーはミラーにすばやく再参加し、バックアップとして機能することができます（または必要に応じてプライマリの役割を引き継ぐことができます）。
この手法の利用に関する情報は、InterSystemsのホワイトペーパー「高可用性手法」を参照してください。
クラウドにミラーを導入できますか？
ミラーリングは効果的にクラウドに導入できます 。 クラウドネットワークの制限により、フェイルオーバーした後に仮想IPアドレス（ミラーVIP）を使用してアプリケーションの接続をリダイレクトすることは通常は不可能ですが、これはロードバランサーなどのネットワークトラフィックマネージャーを使用することで実質的に解決できます 。
ミラーの基本的な設計はどうなっていますか？
通常、Cachéミラーにはフェールオーバーメンバーと呼ばれる物理的に独立したホスト上の2つのCachéインスタンスが含まれています。ミラーによってプライマリの役割が自動的に片方のインスタンスに割り当てられ、もう片方はバックアップになります。 アプリケーションがプライマリのデータベースを更新するいっぽうで、ミラーはバックアップのデータベースをプライマリのデータベースと同期させます。
プライマリに障害が発生するか使用できなくなると、バックアップが自動的にプライマリの役割を引き継ぎ、アプリケーションの接続がそちらにリダイレクトされます。 また、プライマリインスタンスが稼働できる状態に復帰したら自動的にバックアップになります。
メンテナンスやアップグレードのための計画停止中に可用性を維持するため、オペレーターは手動でフェールオーバーさせることができます。
ミラーには、必要に応じて災害復旧とビジネスインテリジェンス、およびデータウェアハウジングを目的とした非同期メンバーと呼ばれる追加のメンバーが含まれます。
ミラーは災害復旧が主な目的である場合など、1つのフェールオーバーメンバーと複数の非同期メンバーで動作することもできます。
データベースのコピーは、実際の本番データベースとどのように同期されますか？
ミラーのバックアップと非同期メンバーは、最後にバックアップされてからCachéインスタンスのデータベースに加えられた時系列の変更記録を含むジャーナルファイルを使用してプライマリと同期されます。 ミラー内ではプライマリからジャーナルファイルが送信され、他のメンバー上で記録が取り込まれます。つまり、ジャーナルファイルに記録された変更がデータベースのローカルコピーに適用され、プライマリの最新の状態に維持されます。
ジャーナルレコードはプライマリからバックアップに同期的に転送され、プライマリは要所要所でバックアップの承認を待ちます。 このような仕組みによってフェールオーバーメンバーが厳密に同期され、バックアップが有効になり、プライマリの役割を引き継げるようにもなります。 非同期メンバーはプライマリから非同期的にジャーナルデータを受信するため、結果としていくつかのジャーナルレコードを遅れて受信することがあります。
自動フェールオーバーはどのようにトリガーされますか？ フェールオーバーで対応できない状況はありますか？
バックアップが自動的に役割を引き継げるのは、手動操作を行わなくてはプライマリを動作させることができなくなったことを認識した場合だけです。 フェールオーバーメンバー間の直接通信が途切れると、バックアップは両方のフェールオーバーメンバーと独立した接続を維持している3番目のシステムであるアービターの力を借りてこの状況を確認します。
また、バックアップがプライマリの最新ジャーナルデータを持っていることや取得できていることを確認できない場合、自動フェールオーバーは発生しません。 ISCAgentsと呼ばれる各フェールオーバーホスト上のCachéインスタンスとは独立して実行されるエージェントのプロセスが、この動作や自動フェールオーバーのロジックやメカニズムの他の場面に関与しています。
アービターが適切に機能していると仮定すれば、ほぼあらゆるプライマリの計画外停止に対応できます。有効なバックアップが障害が発生した、あるいは利用不可能なプライマリから役割を引き継ぐのを妨げるのは、両方のフェールオーバーメンバーをお互いに、さらにはアービターから分離するようなネットワーク障害だけです。
ミラーは災害復旧(DR)機能を提供しますか？
非同期ミラーメンバーの種類の1つに、災害復旧（DR）非同期メンバーがあります。 DR非同期メンバーはプライマリ上のデータベースをすべてミラーリングしたデータベースのコピーを持ち、いつでもフェールオーバーメンバーに昇格できます。 停止によってミラーの中に機能するフェールオーバーメンバーが存在しなくなる場合、昇格されたDR非同期メンバーに手動でフェールオーバーさせることができます。その場合のデータ損失範囲は、停止が発生した時点でDR非同期メンバーがプライマリからどの程度遅れているか、ならびに旧プライマリのホストシステムが機能しており、追加のジャーナルデータを取得できるかどうかによって決まります。 昇格されたDR非同期メンバーは、その他多くの計画停止や計画外停止の状況でも役立ちます。
ミラーの計画
ミラーのアーキテクチャはどのように計画すべきですか？ メンバー構成や物理的配置はどのようになりますか？
ミラーのサイズ・メンバー構成・物理的配置は、ミラーを導入する理由やインフラストラ上および運用上の多くの要因によって決まり、非常に多くの構成が可能です。
2つのフェイルオーバーメンバーを持つミラーは、自動フェールオーバーによって高可用性を実現します。 オプションの非同期メンバーのうち、1つ以上のDR非同期メンバーがデータセキュリティ機能と災害復旧機能を提供できますが、レポート非同期メンバーはデータマイニングやビジネスインテリジェンスなどの目的に使用されます。 単一のレポート非同期メンバーは最大10個の独立したミラーに属することができ、企業全体のデータウェアハウスとして機能し、別々の場所から関連するデータベース一式をまとめることができます。
自動フェールオーバーが必要でない限り、ミラーは単一のフェールオーバーメンバーと、災害復旧およびレポート作成を目的とした多数の非同期メンバーで構成することもできます。
ミラーには最大で16個のメンバーを含めることができます。 フェールオーバーメンバーは遅延の少ない接続が必要とされるために通常は同じ場所に配置されますが、非同期メンバーはローカルまたは個別のデータセンターに配置できます。
複数のミラーメンバーを単一のホストに組み込むことができますが、計画が別途必要になります。
ネットワークや遅延に関してどのようなことを考慮すべきですか？ ミラーにはどのようなネットワーク構成が必要ですか？
重要なネットワーク構成の考慮事項には、アプリケーションのパフォーマンスに関する重要な考慮事項である信頼性、帯域幅、ネットワークの遅延時間などがあります。 通常はプライマリから他のメンバーに転送されるジャーナルデータを圧縮することが好まれますが、常にそうであるとは限りません。
ミラーを支えるのに必要なネットワーク構成を計画する前に、各ミラーメンバーがさまざまな目的に使用される複数の異なるネットワークアドレスを持っていることを理解する必要があります。 ミラー構成およびネットワーク構成のサンプルが、必要なネットワーク構成を定義するのに役立ちます。このサンプルでは、単一のデータセンター、コンピュータールーム、またはキャンパス内のミラー、およびデュアルデータセンターを使ってDR機能を地理的に分散したミラーを紹介しています。
フェイルオーバー時にアプリケーションの接続を新しいプライマリにリダイレクトするためのオプションにはどのようなものがありますか？
ミラーリングとCachéには、ミラー用の仮想IPアドレス（VIP）の使用、ECPデータサーバーのミラー接続としての認識、ミラー対応のCSPゲートウェイといった複数の自動リダイレクトオプションが組み込まれています。
ミラー用のVIPは一般的に非常に効果的なソリューションですが、ネットワーク構成関連を中心にいくつかの事前計画が必要になります。
ロードバランサーなどのネットワークトラフィックマネージャーの使用、自動または手動でのDNSの更新、アプリケーションレベルのプログラミング、ユーザーレベルの手順を含め、さまざまな外部テクノロジーも利用できます。
ミラー内のCachéインスタンスの互換性要件にはどのようなものがありますか？
ミラーに追加するシステムを決める前に、Cachéインスタンスとプラットフォームのエンディアンに関する要件を必ず確認してください。 フェールオーバーメンバーはいつでもプライマリおよびバックアップとしての役割を交換できるため、できるだけ同じようなシステムにしなければなりません。CPUとメモリは同じまたは近い構成に、ストレージサブシステムは同等にしなければなりません。
既存のデータベースをミラーに移行するには？
任意のCachéデータベースをミラーに簡単に追加できます。必要なのはデータベースをバックアップして復元する機能か、CACHE.DATをコピーする機能のいずれかだけです。 手順については、次のセクションで説明します。
仮想化環境にミラーを導入する場合に考慮すべきことはありますか？
仮想化環境でミラーリングを使用する場合、仮想ミラーメンバーホストと物理ホスト・ストレージ間の正しい関係を計画することが重要です。ミラーと仮想化プラットフォームの両方の側面から見た重要な運用上の考慮事項もあります。
ミラーの設定
どのような構成ガイドラインを考慮する必要がありますか？
ミラー仮想IPアドレス（VIP）を構成する場合、InterSystemsは同じスーパーサーバーポートとウェブサーバーポートを使用するようにフェールオーバーメンバーを構成することを推奨しています。
プライマリフェールオーバーメンバー上のCachéインスタンス構成（ユーザー、役割、名前空間、マッピングなど）やミラー化されていないデータ（SQLゲートウェイやウェブサーバー構成に関連するファイルなど）は、他のミラーメンバー上のミラーによって複製されません。 したがって、バックアップやDR非同期メンバー（昇格されている場合もあります）がフェールオーバー発生時にプライマリから役割を引き継ぐために必要なすべての設定やファイルをそれらのメンバーに手動で複製し、必要に応じて更新する必要があります。
ミラーメンバーとして構成されているシステムではインターネット制御メッセージプロトコル（ICMP）を無効にしないでください。ミラーリングはICMPを利用してメンバーが到達可能かどうかを検出しています。
ジャーナリングはミラー同期の基礎であるため、一般的にはフェールオーバーメンバーのジャーナリングのパフォーマンスを監視および最適化し、ジャーナリングのベストプラクティスに従うことが不可欠です。 InterSystemsでは特にすべてのミラーメンバーで共有メモリヒープサイズを増やすことを推奨しています。
ミラーを保護するには？
ミラーリング通信の保護には、X.509証明書を使用してミラー内の全トラフィックを暗号化するSSL/TLSが主に使用されます。 SSL/TLSによる保護を強く推奨します。 ミラーでSSL/TLSを有効にするには、最初に各ミラーメンバーでミラーのSSL/TLS構成を作成する必要があります。ミラーを作成する前にこの構成を行うのが最も便利かもしれません。 SSL/TLSが有効になっている場合、ミラーに追加される各メンバーはプライマリ側で承認を受ける必要があります。あるメンバーのX.509証明書が更新された場合も同様です。
SSL/TLSを使用するミラーに対する保護をさらに強化するため、ジャーナルの暗号化を有効化することができます。 これにより、ジャーナルレコードはプライマリ上で作製される際に有効な暗号鍵のいずれかを使用して暗号化され、他のメンバー上でジャーナルが取り込まれる前に復号化されます。 バックアップとすべての非同期メンバーでは同じ鍵を有効化する必要があり、バックアップとDR非同期メンバーもその鍵を使用してデータを暗号化する必要があります。
ミラーが使用するネットワークを構成する方法も、ミラーの安全性に重大な影響を及ぼします。
ミラー仮想IPアドレス（ミラーVIP）を構成するには？
ミラーVIPは、ミラーを作成する際やメンバーを追加する際、またはミラーを変更する際に詳細を入力することで構成されます。ただし、必要な情報を特定したり、場合によってはミラーメンバーのホストやCachéインスタンスを構成したりといった準備が必要になります。
アービターはどこにどのように配置すべきですか？
アービターは、アービターとフェールオーバーメンバーの計画外停止が同時に発生するリスクを最小限に抑えるように配置すべきです（両方のフェールオーバーが発生した場合、アービターは無意味になります）。そのため、アービターの配置場所は主にフェイルオーバーメンバーの場所によって決まります。 複数のミラーがある場合、それぞれに対して適切に配置されているという条件で単一のシステムをアービターとして構成できます。 1つのミラーに対して1つ以上のフェイルオーバーメンバーかDR非同期メンバーをホストしているシステムは、そのミラーのアービターとして構成しないでください。
Cachéバージョン2015.1以降のインスタンスを1つ以上ホストしているシステムなど、バージョン2015.1以降のISCAgentを実行しているシステムはアービターとして構成できます。 ISCAgentをインストールすることで、2015.1未満のCachéインスタンスをホストしているシステムを含む他のサポート対象システム（OpenVMSシステムを除く）をアービターとして構成できます。
ISCAgentをインストールして起動するには？
ISCAgentはCachéと一緒に自動的にインストールされるため、すべてのミラーメンバーにインストールされています。 ただし、エージェントは各ミラーメンバーのシステム起動時に起動するよう構成する必要があります。
ミラーを作成して構成するには？
ミラーを構成するには、次のような複数の手順を実施する必要があります。
- 2番目のフェールオーバーメンバーを構成する（必要な場合）
- 2番目のフェールオーバーメンバーを承認する（SSL/TLSを使用する場合に推奨）
- 非同期ミラーメンバーを構成する（必要に応じてDRまたはレポートのいずれかを構成）
- 新しい非同期メンバーを承認する（SSL/TLSを使用する場合に推奨）
これらの手順のいずれかを完了すると、Mirror Monitorでミラーの状態を調査し、意図したとおりの結果を得られたかを確認することができます。
ミラーデータベースを作成するには？ 既存のデータベースをミラーに追加するには？
データベースをミラーに追加する前に、ミラーリングできるものとできないもの、ミラーリングとシャドーイングの同時使用、ミラーリングデータベースのプロパティの伝播、およびミラーリング対象となっているインスタンスごとのデータベースの最大数に関する一定のミラーデータベースの考慮事項を確認することをお勧めします。
ミラーデータベースの作成と既存データベースの追加手順は異なります。ミラーデータベースへの変更はミラーされたジャーナルファイルに記録され、非ミラージャーナルファイルとは異なるからです。 データベースがミラーデータベースとして作成されている場合は最初からミラージャーナルファイルが使用されます。そのため、プライマリを始めとする各ミラーメンバーに同じミラー名のミラーデータベースを作成することで、簡単に新しいデータベースをミラーに追加することができます。
プライマリ上にミラーデータベースとして既存の非ミラーデータベースを追加する場合、非ミラージャーナルファイルからミラージャーナルファイルを使用するように切り替わります。 そのため、単純に他のメンバー上にデータベースを作成することはできません。なぜなら、ミラーは非ミラージャーナルファイルを他のメンバーに転送できないからです。 代わりに、データベースがプライマリのミラーに追加された後にデータベースをバックアップして他のメンバーに復元するか、そのCACHE.DATファイルを他のメンバーにコピーする必要があります。
フェールオーバーした後、ECPにアプリケーションサーバーの接続をリダイレクトさせるには？
ミラーVIPを構成したかどうかにかかわらず、接続する各ECPアプリケーションサーバー上のミラー接続としてミラーECPデータサーバーを構成することにより、ECP接続を新しいプライマリにリダイレクトさせることができます。 （アプリケーションサーバーは指定されたホストから定期的に情報を収集し、フェールオーバーを自動的に検出して新しいプライマリに切り替えるため、VIPを使用しません。）
クラウドなどでミラーVIPが使用できない場合にアプリケーションの接続をリダイレクトさせるには？
ミラーVIPはミラーメンバーが同じネットワークサブネット上にある場合にのみ使用できますので、一般的にはミラーメンバーが別々のデータセンターにある場合は使用できません。 同様の理由で、VIPは一般的にクラウドに導入できるオプションではありません。
VIPと同レベルの透過性を実現するために使用され、クライアントアプリケーションやデバイスに単一のアドレスを提示するロードバランサーなどのネットワークトラフィックマネージャーの使用（物理または仮想）を含め、さまざまな外部テクノロジーも利用できます。 その他に想定される手順には、自動または手動でのDNSの更新、アプリケーションレベルのプログラミング、およびユーザーレベルの手順などがあります。
Cachéシャドウをミラーに変換するには？
ミラーリングは、シャドウのソースと宛先、およびそれらの間にマッピングされたシャドウデータベースをプライマリ、バックアップまたは非同期メンバーを含むミラーとミラーベーデータベースに変換するシャドウ・ミラーユーティリティを提供します。
他にどのような構成情報を調べる必要がありますか？
通常はデフォルトで十分ですが、必要に応じてISCAgentポート番号をカスタマイズできます。
プライマリフェールオーバーメンバーでは、必要に応じて既存の^ZSTUまたは^ZSTARTルーチンからユーザー定義の^ZMIRRORルーチンにコードを移動することができます。これにより、特定のミラーリングイベント用に独自構成固有のロジックと機構をミラーが初期化されるまで実行しないように実装することができます。
Ensembleでミラーリングを使用する場合、ミラーデータを含むEnsemble名前空間の特別な要件とミラー環境でのEnsemble Autostartの機能に注意する必要があります。
ミラーの管理
ミラーの動作状態を監視するには？
任意のミラーメンバーのCaché管理ポータルで読み込めるMirror Monitorでは、以下の詳細な情報を確認できます。
- SSL/TLSを使用中のメンバーのx.509 DNを含むミラーとその各メンバーの動作状態。
- フェールオーバーメンバーの場合は、両方のフェールオーバーメンバーのネットワークアドレスとアービターの接続状態、およびアービターのアドレス。非同期メンバーの場合は、レポート非同期メンバーが属するミラー。
- バックアップおよび非同期メンバーの場合は、プライマリからのジャーナルデータ転送とジャーナルデータの取り込みの状態、およびプライマリから届くジャーナルデータの転送速度。
- Mirror Monitorを読み込むメンバー上のミラーデータベースの状態。
Mirror Monitorでは、メンバーのジャーナルファイルの表示や検索、DR非同期メンバーのフェールオーバーメンバーへの昇格・バックアップのDR非同期メンバーへの降格、ミラーデータベースの有効化・キャッチアップ・削除などのさまざまな操作を実行できます。
ミラーメンバーのミラー通信プロセスを監視するため、該当ミラーメンバーの%SYS名前空間でCachéシステム状態ルーチン（^%SS）を使用できます。
ミラーを変更するには？変更できる設定は？
ミラーの構成（SSL/TLS、ミラーVIPその他）を変更したり、ネットワーク構成変更時にメンバーのネットワークアドレスを更新したりするには、プライマリでミラーを編集してください。 また、プライマリのミラーを編集して他のメンバー上でのX.509証明書の更新を承認する必要があります。
非同期の種類を変更し、レポート非同期メンバーを別のミラーに追加し、その他非同期メンバー固有の変更を行うには、非同期メンバーのミラーを編集してください。
Mirror Monitorを使用して任意のメンバー（およびそのメンバーのみ）のミラーからミラーデータベースを削除できますが、その影響は関連するメンバーの種類によって異なります。
ミラーにメンバーを追加できますか？ メンバーを削除できますか？ ミラーを完全に削除するには？
ミラーにはいつでも合計16メンバーの上限まで非同期メンバーを追加できます。 フェールオーバーメンバーが1つで非同期メンバーが15未満の場合はいつでもバックアップを追加できます。 DR非同期メンバーを昇格してフェールオーバーメンバーにすることでバックアップを置き換え、現在のバックアップをDR非同期メンバーに自動的に降格させることもできます。
任意のメンバーでミラーを編集し、ミラーからそのメンバーを削除できます。 ミラーを完全に削除するには、特定の順序でメンバーを削除し、追加の手順を実行する必要があります。
メンバーをミラーから一時的に削除する必要がある場合は？
Mirror Monitorを使用すればメンテナンスや（非同期メンバーの場合に）ネットワーク負荷軽減などを目的としてミラーからメンバーを切り離すことで、無期限にバックアップまたは非同期メンバーのミラーを停止することができます。
非同期メンバーでは、プライマリから非同期メンバーへのジャーナルデータ転送を止めることなくミラー内の全データベースに対してジャーナルの取り込みを停止することもできます。
ミラーはまとめてアップグレードする必要がありますか？ そのためには、ミラーを本番環境から外す必要がありますか？
ミラーを構成するすべてのフェールオーバーメンバーとDR非同期メンバーは同じバージョンのCachéでなければならず、違っていても構わないのはミラーをアップグレードする間だけです。 アップグレードされたメンバーがプライマリになると、他のフェールオーバーメンバーやDR非同期メンバーは同様にアップグレードされるまで使用できなくなります。 一般的に、レポート非同期メンバーを同じバージョンに同時にアップグレードするのがベストプラクティスとされています。
アップグレード手順は、メンテナンスリリースのアップグレード、ミラーデータベースへの変更を一切伴わないメジャーアップグレード、ミラーデータベースへの変更を伴うメジャーアップグレードのどれを行うかによって決まります。 定められた手順は、アプリケーションのダウンタイムを最小限に抑えるよう工夫されています。通常、最初の2つのケースではダウンタイムを完全員回避できます。また、最後のケースでは一般的に計画フェールオーバーを実行して必要なミラーデータベースの変更にかかる時間内に限定されます。
計画ダウンタイム中にメジャーアップグレードを行い、アプリケーションのダウンタイムを最小限に抑える必要がない場合に採用できるより簡単な手順もあります。
他にどのようなミラーまたはミラー関連の管理手順と情報を知っておくべきですか？
各メンバーに有効なミラーのSSL/TLS構成があるという前提で、まだそれを利用していないミラーのSSL/TLS保護を有効化できます。
ミラーにSSL/TLS保護を使用しており、プライマリ上のジャーナルデータを暗号化する有効な暗号鍵がバックアップとすべての非同期メンバーで有効化されているという前提で、ジャーナルの暗号化を利用していないミラーでジャーナルの暗号化を有効化できます。
ハードウェアとネットワークの構成に応じてミラーのサービス品質タイムアウト（QoSタイムアウト）設定を調整することができます。この設定はフェールオーバー機構で重要な役割を果たします。 一般的に、専用ローカルネットワークを持つ（仮想化されていない）物理ホストに展開されたミラーでより迅速な停止への対応が求められる場合にこの設定を減らすことができます。
ミラーデータベースの更新内容の大部分が高圧縮データ（圧縮済みの画像など）や暗号化されたデータである場合、ジャーナルデータの圧縮は効果的ではないと予想され、CPU時間を浪費する可能性があります。 このような場合は、ミラーを構成または変更してジャーナルデータを非圧縮に設定することができます。 （Cachéデータベースの暗号化やジャーナルの暗号化を利用しても、圧縮を選択したことにはなりません。）
プライマリと他のミラーメンバー間のネットワーク遅延が問題になる場合は、プライマリおよびバックアップ/非同期メンバーがそれぞれ適切なサイズの送信および受信バッファを確立できるようにオペレーティングシステムのTCPパラメーターを微調整することで遅延を緩和できる場合があります。
^MIRRORルーチンはあらゆるミラーリングタスク用に、管理ポータルの代わりとなるコマンドラインを提供します。 SYS.Mirror APIは管理ポータルと^MIRRORルーチンを通じて利用可能なミラー操作をプログラムで呼び出すためのメソッドを提供します。
ミラーの停止手順
さまざまな計画的および計画外のミラー停止シナリオに対処するための推奨手順の概要については、ミラーの停止手順を参照してください。