タグ付けされた質問 「availability-groups」

可用性グループはSQL Server 2012の新機能であり、1つまたは複数のSQL Serverデータベースに継続的なデータ同期、自動フェイルオーバー、セカンダリ読み取りアクセスを提供します。

4
クラスタリングとトランザクションレプリケーションと可用性グループ
1台のサーバーマシンに障害が発生した場合でも、データベースバックエンドが24時間利用可能であるため、SQL Server 2012に依存するアプリケーションを確認する必要があると仮定します。 DBAではなく開発者として、フェールオーバー/高可用性にどのシナリオを使用するかを理解するのに苦労しています。 Windowsフェールオーバークラスター内の2つ（またはそれ以上）のサーバー、クラスター化されたインスタンスとしてのSQL Server トランザクションレプリケーションで最新の状態に保たれる2つ（またはそれ以上）のSQL Serverインスタンス 同期コミットモードで構成されたSQL Server可用性グループ内の2つ（またはそれ以上）のSQL Server これらのシナリオのどれが、どのような種類のワークロードで機能し、どのような種類の障害/停止がそれらのシナリオで処理できるのでしょうか？彼らは同等/交換可能ですか？
8
SQL Serverエージェントのジョブと可用性グループ
SQL Server 2012可用性グループでスケジュールされたSQL Serverエージェントジョブを処理するベストプラクティスを探しています。たぶん何かを見逃したかもしれませんが、現在の状態では、SQL Server Agentはこの優れたSQL2012機能と実際には統合されていないと感じています。 スケジュールされたSQLエージェントジョブにノードの切り替えを認識させるにはどうすればよいですか？たとえば、1時間ごとにデータをロードするジョブをプライマリノードで実行しています。プライマリがダウンした場合、プライマリになったセカンダリでジョブをアクティブにするにはどうすればよいですか？ セカンダリで常にジョブをスケジュールすると、セカンダリは読み取り専用であるため失敗します。
5
DMVから、接続がApplicationIntent = ReadOnlyを使用したかどうかを確認できますか？
Always On可用性グループがセットアップされており、ユーザーが接続文字列でApplicationIntent = ReadOnlyを使用していることを確認したい。 DMV（または拡張イベントなど）を介してSQL Serverから、ユーザーが接続文字列でApplicationIntent = ReadOnlyで接続したかどうかを確認できますか？ 接続を防止する方法については答えないでください-それはこの質問の目的ではありません。適切な文字列なしで接続している既存のアプリケーションがあるため、単純に接続を停止することはできません。どのアプリケーションであるかを知る必要があります。 ユーザーが複数のアプリケーションを持っていると仮定します。たとえば、ボブはSQL Server Management StudioおよびExcelに接続します。彼は、更新を行う必要があるときにSSMSに接続し、読み取りを行う必要があるときにExcelに接続します。彼がExcelに接続するときにApplicationIntent = ReadOnlyを使用していることを確認する必要があります。（これは正確なシナリオではありませんが、説明するには十分です。）
3
サーバーの再起動後にSQL Server分散可用性グループデータベースが同期しない
SQL Serverで大規模なアップグレードを実行する準備ができており、先に進む前に解決しようとしている分散可用性グループの異常な動作に気付いています。 先月、リモートセカンダリサーバーをSQL Server 2016からSQL Server 2017にアップグレードしました。このサーバーは、複数の分散可用性グループ（DAG）と個別の可用性グループ（AG）の一部です。このサーバーをアップグレードしたときに、サーバーが読み取り不能な状態になることを認識していなかったため、この1か月間はプライマリサーバーのみに依存していました。 今後のアップグレードの一環として、CU 4パッチをサーバーに適用し、再起動しました。サーバーがオンラインに戻ったとき、パッチを適用したばかりのセカンダリは、すべてのDAG / AGが問題なく同期していることを示しました。 ただし、プライマリーは非常に異なるストーリーを示していました。報告していた 別のAGが問題なく同期していた しかし、DAGは非同期/非正常状態でした 最初にパニックに陥った後、次のことを試みて、DAGで再び同期を取りました。 プライマリから、データの移動を停止して再開しました。これはデータの同期を開始しませんでした。 セカンダリ（パッチを適用したばかりの）ALTER DATABASE [<database] SET HADR RESUME;で実行しました-エラーなしで実行されますが、同期は再開されませんでした データを再び同期する最後の試みは、セカンダリにログインし、SQL Serverサービスを手動で再起動することでした。サービスを手動で再起動するのは少し極端に思えます。サーバーを再起動すれば十分だったと思うからです。 再起動後にDAGがセカンダリへの同期を開始しないという問題に誰かが遭遇しましたか？もしそうなら、それはどのように解決されましたか？ SQL Serverのエラーログとセカンダリサーバーのイベントビューアーの両方を確認しましたが、目に見える異常はありませんでした。
1
可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響しますか？
SSRSおよびTableauのレポート用に、リアルタイムまたはほぼリアルタイムのデータを提供する必要があります。実稼働OLTPシステムが長時間実行されるクエリによって悪影響を受けるのは望ましくありません。可用性グループのセカンダリデータベースで大きなクエリを実行すると、プライマリデータベースのトランザクションパフォーマンスに影響しますか？
2
500データベースのSQL Server 2017-CU9以降頻繁にAGが切断する
みなさん、こんにちは。あなたの助けに感謝します。SQL Server 2017可用性グループで課題が発生しています。 バックグラウンド 会社は小売B2Bバックエンドソフトウェアです。約500の単一テナントデータベース、およびすべてのテナントで使用される5つの共有データベース。ワークロードの特性は主に読み取られ、データベースの大部分のアクティビティは非常に低くなっています。 コロケーションでホストされている物理的な運用サーバーは、共有SAN / FCI構成のWindows Server 2012上のSQL Server 2014 Enterpriseから、2ソケット/ 32コア/ 768 GB RAMおよびローカルのWindows Server 2016上のSQL Server 2017 Enterpriseに最近アップグレードされましたAlwaysOn AGを使用したSSDドライブ。AGトラフィックは、クロスケーブル接続で専用の10G NICポートを使用します。 それらの要件は、すべてのデータベースが一緒にフェールオーバーすることであるため、すべてを単一のAGに配置する必要がありました。これは、同一サーバー上の単一の読み取り不可能な同期レプリカです。 新しいサーバーは、2018年6月から運用されています。最新のCU（当時のCU7）とWindowsの更新プログラムがインストールされ、システムは正常に機能していました。約1か月後、サーバーをCU7からCU9に更新した後、サーバーは優先度の高い順に以下の課題に気付き始めました。 SQL Sentryを使用してサーバーを監視しており、物理的なボトルネックは観察されていません。すべての重要な指標は良いようです。CPUは平均20％、IO時間は通常1ミリ秒未満、RAMは完全に使用されておらず、ネットワークは1％未満です。 課題 フェールオーバー後に症状は良くなるようですが、どちらのサーバーがプライマリであるかに関係なく、数日以内に戻ってきます。症状は両方のサーバーで同じです。 次のような散発的なクライアントタイムアウトと接続障害 ...接続の確立中にエラーが発生しました... または 実行タイムアウトが切れました 場合によっては、これらは最大40秒間続き、その後沈静化します。 トランザクションログバックアップジョブの完了には、以前よりも10倍時間がかかります。以前は、500個すべてのデータベースのログをバックアップするのに2〜3分かかりましたが、現在では15〜25分かかります。バックアップ自体が良好なスループットで正常に実行されることを確認しました。ただし、1つのログのバックアップが完了してから次のログを開始するまでにわずかな遅延があります。非常に低い値から始まりますが、1〜2日で2〜3秒かかります。500個のデータベースを乗算すると、違いがあります。 時々、ランダムに見える一部のデータベースが、手動フェールオーバー後に「同期していない」状態のままになります。これを解決する唯一の方法は、セカンダリレプリカでSQL Serverサービスを再起動するか、これらのデータベースを削除してAGに再結合することです。 CU10で導入された別の問題（CU11では解決されていません）：master.sys.databasesでのブロッキングのセカンダリタイムアウトへの接続、およびセカンダリレプリカにSSMSオブジェクトエクスプローラーを使用することさえできません。根本的な原因は、Microsoft SQL Server VSSライターが次のクエリを発行してブロックしているようです。 select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from …
1
AlwaysOn AG、フェールオーバー付きDTC
問題： AlwaysOn可用性グループ（AG）のすべてのサーバーで分散トランザクションコーディネーター（DTC）を実行するにはどうすればよいですか？フェールオーバー/スイッチオーバーイベントでトランザクションを維持する必要はありません。 セットアップ： Windows 2012フェールオーバークラスター（WSFC）に3台のWindows 2008 R2サーバーがあり、すべてSQL 2012を実行しています。2つのサーバーが1つのデータセンターにあり、AlwaysOnフェールオーバークラスター（FCI）の一部であり、 2番目のデータセンター。WSFCはマルチサブネットクラスターです。セットアップのスケッチは次のとおりです。 2つのFCIノードは同じサブネット上にあり、ストレージを共有しているため、2つのFCIノード間で動作するようにDTCをインストールおよび構成できました。いくつかのAGを構成しましたが、正常に機能しています。このスクリーンショットは、FCIにインストールされたDTCを示しています。 このスクリーンショットは、FCIノードのいずれか（アクティブな方）でDTCを構成できることを示しています。 DTCを使用するアプリケーションをこのクラスターに移行し、AGを使用したいと思います。私は、DTCがAGでサポートされていないことを読みました（参照）。2番目のデータセンターの3番目のノードでDTCを構成する方法を見つけることができませんでした。3番目のノードでDTCを構成しようとすると、次のスクリーンショットに示すように、DTCを使用できないようです。 Brent Ozarの無料セットアップチェックリストPDFに、可用性グループのリストがあります。 クラスターのインストール... 29. FCIが関係する場合は、計画セクションの決定に従ってDTCを構成します。 SQL Server 2012のAlwaysOn可用性グループに関するコメントで、Rock Brent氏は次のように述べています。「... ..」 これにより、AGスイッチオーバーでトランザクションが維持されないことを理解している限り、可用性グループでDTCを使用できるように見えます。FCIノードからのトランザクションを維持するためには必要ありません。壊滅的な災害（プライマリデータセンターを失った）の場合に使用するアプリケーションにDTCが必要なだけです。 3番目のノードでDTCを構成するにはどうすればよいですか？または、AGとDTCを必要とするアプリケーションの使用に関して、私は運が悪いのですか？ 更新：私が解決した解決策は、ログ配布を使用することです。ただし、フェールオーバーの場合、Node3でDTCを使用できるようにする必要があります。Node1とNode2の間で共有されているDTCのクラスター化されたMSDTC-MSSQLSERVERCLUインスタンスをアンインストールすることで利用可能になることを発見しました。削除したら、Node3でLocalDTCインスタンスをセットアップおよび構成できます。その後、クラスター化されたMSDTC-MSSQLSERVERCLUインスタンスを再インストールできます。この順序でインストールシーケンスを実行すると動作するようです。私は今少しの間そのように走っています、そして私はどんな悪影響も発見していません。これは、AlwaysOn可用性グループを実行する場合にも機能するようです。AGフェールオーバーでは分散トランザクションが保持されないことを理解しています。フェールオーバー後に動作するには新しいトランザクションのみが必要です。しかし、私は持っていません
4
RAID1または5の代わりにRAID0これはおかしいですか？
SQL Serverクラスターの1つにRAID0セットアップを使用することを検討しています。私は状況の概要を説明し、これが悪い考えである理由を探しています。また、ユースケース、ホワイトペーパー、または他のドキュメントを持っている人がこのトピックについて私に指摘できるなら、それは素晴らしいことです。 SQLクラスターの一部である2つのデータセンターに3つのサーバーがあります。それらはすべて、可用性グループでSQL Serverを実行しています。プライマリには、すぐ隣にレプリカがあり、もう1つは他のデータセンターにあります。自動フェールオーバーを使用して同期レプリケーションを実行しています。すべてのドライブはエンタープライズクラスのSSDです。SQL Server 2017または2019を実行します。 RAID0アレイで他の方法よりもRAID0アレイ上で実行することには、実際の欠点があったとしてもわずかしかありませんが、複数の利点があると考えています。私が現在見ている唯一のマイナスは、プライマリサーバーの冗長性の欠如です。長所として： 誰かが手動で操作を行うという通知を受け取るまで、速度が低下した状態で実行されるのではなく、ドライブに障害が発生した場合、サーバーはすぐに二次側に障害を起こし、完全な動作能力を維持します。これには、フェールオーバーを通知するという追加の利点があるため、原因をより早く調査できます。 TB容量ごとの全体的な障害の可能性を減らします。パリティドライブまたはミラードライブは必要ないため、アレイあたりのドライブ数を減らします。ドライブが少ないほど、ドライブが故障する可能性が低くなります。 もっと安い。必要な容量に必要なドライブの数が少ないことは明らかにコストがかかりません。 これは従来のビジネス思考ではないことは知っていますが、検討していないことはありますか？私は、賛否両論の入力を歓迎します。 クエリのパフォーマンスを向上させるためにこれをしようとはしていませんが、意味のあるものがあれば、気軽に指摘してください。私の主な関心事は、私が考えていなかった信頼性または冗長性の問題を考慮または対処できないことです。 OSは別のミラードライブ上にあるため、サーバー自体は動作し続ける必要があります。これらのドライブの1つを交換して、再びミラー化できます。それは小さく、システムDB以外のデータベースファイルはありません。数分以上かかるとは想像できません。データアレイの1つに障害が発生した場合、ドライブを交換し、アレイを再構築して、AGと復元および再同期します。私の経験では、復元はRAID5ドライブの再構築よりもはるかに高速です。RAID1で障害が発生したことは一度もないので、その再構築が高速になるかどうかはわかりません。リストアはバックアップから行われ、プライマリと一致するようにロールフォワードされるため、プライマリサーバーの負荷の増加は、回復したレプリカと最後の数分間のログのみを同期する必要があります。
1
読み取り可能なセカンダリの強制計画
可用性グループのプライマリでプランが強制される場合、セカンダリで実行されるクエリに適用されますか？ 私は計画強制の両方の可能性をカバーする答えを探しています： 計画ガイド クエリストアの強制計画 QS強制プランは引き継がれないことを示唆する次の記事を読みましたが、ドキュメント内で信頼できるもの、またはプランガイドに関するものを見つけることができません。 Erin Stellatoによるクエリストアと可用性グループ Vikas RanaによるAlwaysOn Readable Secondaryでのクエリデータストアの強制プランの動作 強制の決定的な証拠は存在だろうUse Planか、PlanGuideNameとPlanGuideDBの二次実行計画のプロパティ。
1
高可用性でのSQL Server 2012データベースの復元
別のインスタンスの別のデータベースと同期された、常時オンの高可用性モードのデータベースがあります。.bakを使用してファイルからプライマリデータベースに復元するにはどうすればよいT-SQLですか？ 私は高可用性に不慣れであり、復元を行う前にデータベースを高可用性から削除してから再び高可用性に戻す必要があるとアドバイスされましたが、よくわかりません。 プライマリAlwaysOnがまだ有効であり、セカンダリと自動的に同期する間に、プライマリに直接復元できることを望んでいます。
4
ログインは可用性グループ間で同期していません
AlwaysOnグループには2台のサーバーがあります。 同期された各データベース内のユーザーアカウントは両方のサーバーに存在しますが、データベースインスタンスレベルのログインはいずれかのサーバーにのみ存在します。つまり、DBINSTANCE-> Security-> Loginsが1つのサーバーにありません。 したがって、フェールオーバーが発生すると、2番目のサーバー（対応するインスタンスレベルのログインがない）でログインエラーが発生します。 この問題を解決するにはどうすればよいですか？ユーザーアカウントを特別な方法で設定することになっていますか？
2
一括挿入の制約のない委任を構成する
Always On可用性グループにMicrosoft SQL Server 2016ノードのペアがあります。BULK INSERTWindows Server 2016ファイルサーバーフェールオーバークラスターにあるファイルに対して（SQL Server 2016 Management Studioクエリを使用して）実行しようとしていますが、次のエラーが表示されます。 メッセージ4861、レベル16、状態1 ファイル "\ nas2.my.domain \ Microsoft SQL Server 2016 Enterprise \ test.txt"を開けなかったため、一括読み込みできません。オペレーティングシステムエラーコード5（アクセスが拒否されました）。 これは、アクティブノード名（nas2.my.domain）またはフェールオーバークラスターリスナー（nas.my.domain）を使用するかどうかに関係なく発生します。 調べてみると、これは、SQL Serverが、ニュアンスが原因で接続しているユーザーアカウントを偽装できないことが原因であることがわかりましたBULK INSERT。 Windows認証を使用してSQL Serverに接続する場合、SQL Serverサービスアカウントは、ファイルサーバーへの接続時にユーザーアカウントを偽装しようとします。SQL Server認証を使用して接続する場合、SQL Serverサービスアカウントとしてファイルサーバーに接続します。 委任と偽装が適切に構成されていない場合（既定の状態）、SQL Serverサービスはユーザーアカウントを偽装できず、匿名ユーザーとしてファイルサーバーに接続しようとします。 これは、ファイルサーバーのセキュリティイベントログを調べることで確認できます。これらの事実は、制約なしおよび制約付き委任の構成に関するガイドとともに、次のリンクに記載されています。 方法：制約付き委任を使用したSQL Server一括挿入（アクセスが拒否されました） 一括挿入とKerberos 私はsqldudeのガイドの指示に従ってみましたが、まだ機能していません。 私が行おうとしBULK INSERTているデータベースは可用性グループの一部ではないため、MSSQL1ノードのみが関連するはずです。ファイルサーバーはNAS2ノードでアクティブでした。ファイルサーバーのイベントログを確認すると、この問題が引き続き発生しており、SQL Serverがユーザーアカウントを偽装するのではなく匿名ユーザーとしてファイルサーバーに認証しようとしていることがわかります。 誰が何が間違っているのか知っていますか？または、これらのガイドを廃止するためにSQL Server 2016で何かが変更された場合はどうなりますか？ ファイルサーバーセキュリティイベントログエントリ サービスアカウントの委任 サービスアカウントSPN SQL …
3
可用性グループデータベースが同期なし/回復保留モードでスタックしている
SQL Server 2014 SP1（12.0.4422.0）インスタンスのストレージをアップグレードしているときに、SQL Serverの再起動後に2つのデータベースがセカンダリで起動しないという問題が発生しました。新しい（大きい）SSDを取り付け、データファイルを新しいボリュームにコピーしている間、サーバーは数時間オフラインでした。SQL Serverを再起動すると、2つを除くすべてのデータベースが再び同期を開始しました。他の2つは、SSMS で同期なし/回復保留中と表示されました。 以前に同様の同期しない/回復中の問題があったため、可用性グループ->可用性データベースセクションでステータスを確認しましたが、赤いXが表示されていました。 データ移動を一時停止しようとすると、エラーメッセージが生成されました。 可用性グループ「SENetwork_AG」の可用性レプリカ「ny-sql03」にあるデータベース「StackExchange.Bycycles.Meta」でのデータ移動の一時停止に失敗しました。（Microsoft.SqlServer.Smo） 追加情報：Transact-SQLステートメントまたはバッチの実行中に例外が発生しました。（Microsoft.SqlServer.ConnectionInfo） ファイル「StackExchange.Bycycles.Meta」にアクセスできません。ファイルにアクセスできないか、メモリまたはディスク領域が不足しています。詳細については、SQL Serverエラーログを参照してください。（Microsoft SQL Server、エラー：945） チェックしたところ、ファイルは存在し、権限の問題はありませんでした。また、管理下のSSMSでSQL Serverログを確認しましたが、保留中の回復や2つのデータベースの問題については何も表示されませんでした。 ヘルプを検索したところ、データベースを復元する必要があると述べた2つの異なる記事が見つかりました。 データベースがリカバリ保留状態でスタックしているときに、セカンダリでデータレプリケーションを再開する方法はありますか？
2
SQL Server 2012可用性グループは「常にオン」ですか？
従来のSQL Serverクラスターでは、フェールオーバーが発生すると、SQL Serverの障害が発生したインスタンスに接続されているすべてのクライアントは接続を失い、各クライアントはフェールオーバークラスターインスタンスへの新しい接続を再確立する必要があります。 AlwaysON可用性グループはこの問題を軽減しますか？SQL Server 2012 AlwaysON可用性グループの場合のフェイルオーバーは、SQL Serverに接続するクライアントに対して透過的ですか？
2
スキーマの変更は可用性グループを「破壊」しますか、それとも透過的に処理されますか？
私の組織はSQL Server 2012可用性グループの採用を計画しており、それがアプリケーションのアップグレードプロセスに与える影響（ある場合）を理解しようとしています。 私たちは8週間のサイクルでアプリケーションの更新をリリースします。どのリリースにもスキーマの変更やデータの移行が含まれる可能性があります。 私が理解しようとしているのは、HA / DRソリューションがスキーマの変更を透過的に処理する（新しい列、インデックスがセカンダリに追加される）かどうか、または各インスタンスでスキーマを作成してからAlways Onをオンに戻すために手動で介入する必要があるかどうかです。 私が想定しているデータ移行の部分は透過的に処理されますが、それも確認したいと思います。 また、可用性グループの構成に基づいてこれらの動作に違いはなく、誤っている可能性もないと全面的に想定しています。私にお知らせください。 一言で言えば; アプリケーションの特定のリリースでは、非常に大きなテーブル（数千から数億のレコード）に列を追加することで、テーブルを変更できます。一部の列は「完全に新しい」ため、Enterprise Onlineのスキーマ変更機能を利用できます。他の列は既存の列のリファクタリングである可能性があり（FullNameはFirstNameとLastNameに分割されます）、これらのフィールドに入力するために、テーブルの各行に対して移行が実行されます。これらの動作のいずれかでは、DBAがAlwaysOn構成を変更する必要がありますか、それともデフォルトで処理され、すべてのセカンダリがDDLおよびDMLステートメントを「無料」で取得しますか？ あなたが提供できる明確さをありがとう。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.