SQL Server ミラーリングで継続的な可用性を実現
データベース ミラーリング ソリューションは、非常にシンプルで中規模以下のデータベースに適した高可用性データベース管理システムを SQL Server に構築するのに役立ちます。
高可用性データベース管理システムの要件はますます緊急になっており、場合によっては組織や企業にとって重要な要素となります。ただし、高可用性 (ほぼ常にアクティブ) を実現するのは簡単ではありません。ハードウェアの問題、ネットワーク インフラストラクチャ、エラー、オペレーティング システム、アプリケーション ソフトウェアのエラー、ウイルスなど、システムのパフォーマンスに影響を与える要因は常に多くあるからです。この記事では、現在使用されているデータベース管理システムであるSQL Server で高可用性 (HA - 高可用性) を実現するためのソリューションを紹介します。 .
SQL Server 上の HA ソリューション
フェールオーバー クラスター
このソリューションでは、共有ハード ドライブ (通常はSAN) を使用します。 データベースを保持します。たくさんの事例があります。 ' SQL Server がインストールされている場合、各インスタンスはノードですが、一度にデータベースを制御できるのは 1 つのノードだけです。このノードに問題が発生すると、別のノードが代わりにデータベースを管理します。
ログ配布
ミラー (コピー) としてのデータベースの追加構造。メイン データベースからの変更または更新があると、これらの変更を記録するログ ファイルがミラー サーバー インスタンスに送信されます。このようにして、データベースの更新されたコピーが維持されます。インシデントが発生した場合、コピー データベースは短時間でメイン データベースに変換されます。
画像 1 :SQL Server セットアップはいつでも利用可能
レプリケーション
フェールオーバー クラスターの場合 とログ配布 は高可用性を確保するための 2 つのソリューションです データベース レベルのレプリケーション テーブル、ビューなどのデータベース内のオブジェクト レベルでの高可用性のみを保証します。これらのオブジェクトは、保存のために SQL Server の 2 番目のインスタンスにコピーされます。
SQL Server のデータ ミラーリング
データベース ミラーリング (DM) は、SQL Server で高可用性データベースを構築するための新しいソリューションです。 DM は、次のような以前のソリューションの欠点を克服します。
• フェールオーバー クラスターとの比較 DM は SAN のような特別なハードウェアを必要としないため、構成コストが削減されます。
• ログ配布との比較 DM は、エラーが発生したときに、管理者が操作することなく自動的にミラー マシンに切り替えることができます。ログ配布には、T-SQL を使用した手動構成が必要です。したがって、中断時間 (ダウンタイム) が秒単位で計算できる場合、DM は「ホット スタンバイ」と呼ばれ、中断時間が分単位以上になる可能性があるため、ログ配布は「ウォーム スタンバイ」と呼ばれます。
• レプリケーションとの比較 , DM はデータベース全体を保護するのに対し、レプリケーションはデータベースの一部 (たとえばマスターなどのテーブル) のみを保護するため、優れています。
ただし、DM はエンタープライズ / デベロッパーでのみ利用できます。 SQL Server 2005 SP1 / 2008 のバージョン。
1. SQL Server の DM の構造
SQL Server の DM には 3 つのメイン インスタンスが必要です。 データベースを管理するための 1 つのインスタンス (プリンシパル ロール)、データベースのバックアップを確保するための追加の 1 つのインスタンス (ミラー)。監視のインスタンスは、2 つのメイン インスタンスとサブインスタンスのインスタンスに接続して、データベースの可用性を監視および確保します。
証人の顔がいる場合: 監視サーバーは、メイン サーバーとミラー サーバーの両方に接続します。これで、システム全体が 3 つのコンポーネントのうち 2 つが決定権を持つ定足数になります。メイン サーバーに問題が発生した場合、監視サーバーは自動的にミラー サーバーをメイン サーバーに切り替えます。その後、メイン サーバーが再び動作している場合、管理者が介入するまで、メイン サーバーはミラー サーバーの役割を引き継ぎます (2 つのサーバーが互いに役割を変更します) (図 1) ).
画像 2 :SQL Server セットアップはいつでも利用可能
監視サーバーがない場合: 自動変換プロセスは、管理者の影響がなければ機能しません。
SQL Server には「エンドポイント」という概念があります。 ' これは「接続ポイント」として解釈でき、SQL Server インスタンスが TCP 経由で相互に通信できるようになります (図 2 ).
各エンドポイントは、対応するアドレスとポートによって識別されます。理論的には、アドレスは完全なドメイン アドレスである必要がありますが、実際には次の 4 つの方法のいずれかで使用できます。
- サーバー名によって決定します。 例:TCP:// プリンシパル:7024.
- ドメイン名によって決定します。 例:TCP://PRINCIPAL.DELTAX.COM:7024.
- IPv4 を通じて決定します。 例:TCP://192.168.1.3:7024.
- IPv6 を通じて決定します。
注: SQL Server インスタンスが同じマシン上で実行されている場合、TCP ポートは異なる必要があります。
2.メインサーバーとセカンダリサーバーの間で情報を交換します。
画像 3 :SQL Server セットアップはいつでも利用可能
高速モード (ハイパフォーマンス):
ハイパフォーマンス モードは、非同期コピーの作成に対応します。メイン サーバーは更新をミラー サーバーに送信し、ミラーリングされたミラー サーバーが正常に更新されなくても、引き続き他の変更を加えます。
ミラー サーバーが変更を更新するのを待たないことで、メイン サーバーのアクセス速度が向上し、不必要なロードが回避されます。
このプロセスは次のスキームで説明できます:
高速モードの場合、ミラー サーバーは常にメイン サーバーよりも更新が遅く、メイン サーバーがデータをサーバーに送信せずに操作を中断した場合、データの損失が発生する可能性があります。鏡。ただし、この異なるデータベース部分は比較的小さく、許容可能です。ハイ パフォーマンス モード - ハイ パフォーマンス モードでは、Witness サーバーは必要ありません。
高安全モード (高安全):
高速モードとは異なり、高安全モードは同期メカニズムを使用します。アプリケーションまたはユーザーが更新されると、メイン サーバーとミラー サーバーの両方でほぼ同時に更新されます。これにより、メイン サーバーに問題が発生した場合でも、ミラー サーバーにデータベースの完全なコピーが確保され、高いデータ セキュリティが確保されます。
高セキュリティ モードでは、ホット スタンバイ - ホット スタンバイを確保するために監視サーバーが必要です。
3. DM 構成:
SQL Server での DM の構成は、3 つの基本的な手順で構成されます。
- メイン サーバーでデータベース全体をバックアップ (バックアップ) し、ミラー サーバーで復元 (復元) します。
- メイン サーバー、ミラー、監視サーバーが連携できるように、対応するエンドポイントを作成します。
- セッション (データベース ミラーリング セッション) を作成します
画像 4 :SQL Server セットアップはいつでも利用可能
DM の構成は、SQL Server Management Studio (SSMS) のインターフェイスを使用して行うことも、T-SQL を使用して構成することもできます。
SQL Server Management Studio のインターフェイスを使用した構成は非常に簡単です。ミラー サーバーにデータを正常に復元した後、データベースを右クリックして [ミラーリング] を選択するだけです。 ' をクリックし、次の手順に従います。
その結果、DM セッションが初期化されます。
SSMS 構成では、T-SQL を使用するとほとんどの操作を削除できますが、必要に応じて、T-SQL を使用して最高の柔軟性を実現することもできます。
T-SQL の構成では、ログインによる検証または証明書による認証の 2 つの方法を使用して他のエンドポイントを認証できます。 T-SQL コードは完成しているため、DM 構成は非常に長いため、いくつかの一般的な手順のみを紹介します。
ログインを伴う設定
同じ方法で SQL Server アカウントを使用する場合、Windows アカウントを使用して SQL Server にログインするとします。
ログインの作成 [PRICIPAL-SRVAdministrator]
窓から
行く
エンドポイントを作成します:
エンドポイントパートナーの作成
状態 =開始済み
AS TCP (LISTENER_PORT =5022)
データベース_ミラーリング用 (
認証 =Windows ネゴシエート、
暗号化 =サポート、
役割 =すべて)
行く
ROLE =ALL を使用してエンドポイントを作成することに注意してください。 プリンシパル サーバーとミラー サーバーの両方で実行する必要があるため、監視サーバーでは ROLE =WITNESS に置き換えます。 .
画像 5 :SQL Server セットアップはいつでも利用可能
証明書による設定:
ログイン アカウントを使用して各エンドポイントが相互に識別できるようにする代わりに、代替ソリューションである証明書を使用して証明書を作成することができます。
- マスター キー暗号化を作成します (証明書のエクスポートに必要):
tạo người dùng key xác thực từ mật khẩu ='abc123 !!';
- 証明書を作成します:
証明書 PRINCIPAL_cert を作成する
件名 ='プリンシパル証明書'、
開始日 ='2007/11/01',
有効期限 ='2020/11/01';
画像 6 :SQL Server セットアップはいつでも利用可能 - 証明書に対応するエンドポイントを作成します。
エンドポイントの作成 endpoint_mirroring state =開始済み
tcp として (listener_port =7024、listener_ip =all)
Database_mirroring の場合 (認証 =証明書 PRINCIPAL_cert、暗号化 =無効、役割 =すべて);
- 証明書を別のファイルにエクスポートします:
証明書 PRINCIPAL_cert を file ='c:PRINCIPAL_cert.cer'; にバックアップします。
ミラー サーバーと監視でも同じことを行い、必要に応じてロール =監視を変更することに注意してください。エンドポイントを作成し、3 つのインスタンスすべてで証明書をエクスポートした後、プリンシパル サーバーに戻ります。
- ミラー サーバーのログインを作成します:
PASSWORD ='abc123 !!' でログイン MIRROR_login を作成します。
行く
- そのログインに対応するユーザーを作成します
ログイン MIRROR_login からユーザー MIRROR_user を作成します。
行く
- サーバーの .cer ファイルから証明書を作成します。
証明書 MIRROR_cert を作成する
認可 MIRROR_user
ファイルから ='c:MIRROR_cert.cer';
行く
- サーバーのログイン ミラーのエンドポイントに接続する権限を付与します:
[MIRROR_login] に CONNECT ON Endpoint ::endpoint_mirroring を付与します。
行く
画像 7 :SQL Server セットアップはいつでも利用可能 3 台のコンピュータが相互に識別および認証できるように、ミラーリングおよび監視サーバーだけでなく、ミラーリング監視サーバー証明書にも同じことを実行します。
エンドポイントを作成した後、次のクエリを使用してエンドポイントを確認できます。
SELECT 名前、state_desc、role_desc
sys.database_mirroring_endpoint から
最後のタスクは、DM のセッションを開始することです。
* プリンシパル サーバー上:
ALTER DATABASE アドベンチャーワークス
SET PARTNER ='TCP://mirror-srv.deltax.com:5022'
行く
* ミラー サーバー上:
ALTER DATABASE アドベンチャーワークス
SET PARTNER ='TCP://pricipal-srv.deltax.com:5022'
行く
* プリンシパル サーバーで、監視サーバーをセットアップします。
ALTER DATABASE アドベンチャーワークス
SET WITNESS ='TCP://witness-srv.deltax.com:5022'
行く
システムの稼働後はデータベース ミラーリング モニターで監視できます。 ツール :
画像 8 :SQL Server セットアップはいつでも利用可能
4.プログラミングミドルウェア:
DMを利用すると、ミドルウェア側からデータベースへの接続がほぼ透過的になると言われています。 ADO.NET ライブラリを使用する場合は、ConnectionString を変更するだけです。 「フェールオーバー パートナー」を追加します。 ' フィールドをミラー サーバーに送信します。例:
データ ソース =pricipal.database.com;フェールオーバー パートナー =Mirror.database.com;初期カタログ =AdventureWorks;
統合セキュリティ =True;
さらに、ADO.NET は「接続プール」を作成します。 ' これにより、開始された接続のキャッシュが可能になるため、サーバーの切り替えにつながる問題が発生した場合には、追加の操作を積極的に実装する必要があります。このキャッシュを削除します。
SqlConnection.ClearPool (conn);
エピローグ
画像 9 :SQL Server セットアップはいつでも利用可能 SQL Server の DM は非常にシンプルで、構成、使用、監視が簡単ですが、その機能は比較的制限されています。これは中規模以下のデータベースにのみ適しており、継続性に対する厳しい要件がある大規模データベースの場合は、提案されたアプローチは満たされていませんが、全体的なオペレーティング システム ソリューションが必要です。ハードウェア システム、ネットワーク。
この記事は、SQL Server で可用性の高いデータベース管理システムを構築する方法の概要を理解するのに役立つことを目的としています。
参照:http://technet.microsoft.com/en-us/library/cc917680.aspx
頑張ってください。
「SQL Server セットアップはいつでも利用可能」という記事を読み終わりました。 " 編集者:TipsMake チーム。この記事が多くの役立つ技術的なヒントやコツを提供できれば幸いです。ヒントやガイドに関する同様の記事を検索できます。読んでいただき、定期的にフォローしていただきありがとうございます。
-
MSSQLServerでのデータベースの監視
監視とは、データベースのステータス(データベース)を確認し、所有者名、ファイル名、ファイルサイズ、バックアップスケジュールを設定することです。 SQL Serverでのデータベースの監視は、主にSQL Server Management StudioまたはT-SQLを介して実行できます。また、サードパーティツール、サーバーでのジョブの作成などの他の方法で制御することもできます。エージェント。 データベースのステータスは、下の画像に示すように接続中(オンライン)、または下の画像に示すように別の状態(オフライン)で確認できます。 データベースは接続状態です TestDBは現在オフライン
-
SQL Server Management Studio18.7の新機能
リリース18.7は、2020年のSSMSの3番目のメジャーリリースであり、データベース管理用の高品質ツールを提供するというコミットメントを拡張します。主な変更点は次のとおりです。 AzureDataStudioを使用してインストール SQL Server Management Studioは、Microsoftデータソリューションを使用する多くの人々のためのクロスプラットフォームツールです。 2018年に最初にリリースされたAzureDataStudioは、クラウドベースおよびアットホームソリューションのAzure Dataファミリーを使用する、データプロフェッショナル向けのオープンソース