1

ミラーリング、クラスタリング、またはその他のフェイルオーバー技術を使用したことはありません。しかし、私の顧客が監視の有無にかかわらずミラーリングを使用することを決定した場合に、SQLNativeClient の透過的なクライアント リダイレクトが機能するように、私の DAL をどのように簡単に適応させることができるかを調査しています。

ミラーリングされ、フェイルオーバーする可能性のあるインスタンスに接続する何百ものデスクトップに配置される可能性のあるクライアント アプリケーションの実用的なプロセスを説明できる人はいますか?

ここでは、100 台のデスクトップ マシンに対してメンテナンス不要のアプローチを考えています。私の現在の考えでは、検出プロセスが自動化されていない場合、どのサーバーがプリンシパルで、どのサーバーがミラーで、どのアプリケーションから読み取ることができるかを説明するインターネット/イントラネット ファイル/サービスが必要になるでしょう。

背景: SQL_COPT_SS_FAILOVER_PARTNER 接続属性の使用に関連する複数の記事を読みましたが、接続文字列でミラーを指定して SQLNCLI 透過的クライアント リダイレクトを許可する必要がありますが、これはすべて少し前後しているようです。なぜプログラマーやエンドユーザーが関与しなければならないのですか? ネットワーク インフラストラクチャは変更される可能性があります。

プリンシパルまたはミラーまたはウィットネスのいずれかに接続しようとすると、正しいプリンシパルに再ルーティングされ、ミラーが何であるかが「わかる」ことを願っています。ミラーリング監視は複数のデータベース ミラーリング セッションを管理できることを理解しているため、別のものが必要になる可能性があります。

では、最初にミラー サーバーまたはプリンシパル サーバーを見つけるにはどうすればよいでしょうか。変更される可能性があるため、ユーザーに入力させたくありません。最初に実行中のプリンシパルに接続し、登録済みのミラーをプリンシパルから抽出してから、それらのパラメーターを使用して再接続する必要がありますか? それとも後で接続属性を設定できますか?

啓蒙期待してます！

4

1 に答える 1

6

First lets take the witness out of the SQL Client equation. The witness is only an affair between the two partners involved in mirroring and does not have to accept client connections. Having the witness accept the client connection and 'redirect' appropriately would require the entire client connection infrastructure to be set up in place on the witness (primarily logins and permissions) and would require the witness to be reachable by the client (at IP level). If you think setting up the logins and permissions is trivial, then think about why MSDN has a dedicated article on this topic: Setting Up Login Accounts for Database Mirroring (hint: 'orphaned users').

Next lets consider how would the client reach the principal OR mirror. Say you only specify one server name in the client connection, the principal, and you connect to it and he'll redirect you to the 'mirror' (actually, to the new principal since the roles swapped and he is now the 'mirror'). This would work, but only in the most uninteresting case: when the principal and mirror are both online and have swapper roles. This is no a disaster recovery scenario, the interesting case is when the principal suffered a catastrophic failure and is unavailable. Ins such a case the former principal is unreachable and the client trying to connect would simply get back cricket chirps, there simply isn't a listener there to redirect him to the former mirror (current principal). This is why the client must know the names of both the principal and mirror.

Now that being said, of course there is nothing preventing you from having a central repository of mirroring pairs and have the client connect to the repository first and retrieve the names of the principal and mirror. You're left with the somehow ambiguous task of discovering the repository and the task of keeping the repository up to date (achievable by leveraging Event Notifications on the Database Mirroring State Change event (EN can deliver remotely to a central repository, see routing). The last task is to make the repository highly available, and again mirroring is the likely solution.

于 2012-02-03T18:04:29.150 に答える