既存のAlwaysOnデータベースでのMicrosoftSQLServerログ配布
この投稿では、既存のMicrosoft®SQLServer®AlwaysOnで構成されたデータベースを使用して、ディザスタリカバリ（DR）ソリューションであるログ配布を設定する方法について説明します。
AlwaysOn可用性グループ（AG）機能は、データベースミラーリングのエンタープライズレベルの代替手段を提供する、高可用性および災害復旧ソリューションです。 SQL Server 2012（11.x）で導入されたAlwaysOn AGは、企業のユーザーデータベースのセットの可用性を最大化します。AGは、可用性データベースと呼ばれる、一緒にフェイルオーバーするユーザーデータベースの個別のセットのフェールオーバー環境をサポートします。また、一連の読み取り/書き込みプライマリデータベースと1〜8セットの対応するセカンダリデータベースもサポートします。オプションで、AGはセカンダリデータベースを読み取り専用アクセスと一部のバックアップ操作に使用できるようにすることができます。
SQL Serverのログ配布を使用すると、プライマリサーバーインスタンスのプライマリデータベースから個別のセカンダリサーバーインスタンスの1つ以上のセカンダリデータベースにトランザクションログバックアップを自動的に送信できます。トランザクションログバックアップは、各セカンダリデータベースに個別に適用されます。
プライマリレプリカサーバーとセカンダリレプリカの間にAlwaysOnセットアップを構成し、メインデータセンターでAlwaysOnが使用されていると仮定します。必要なWindowsServerフェールオーバークラスター（WSFC）構成をDRサイトに展開できない場合は、ログ配布を使用する必要がある場合があります。理由には、次の可能性が含まれます。
- インフラストラクチャまたはスタッフは、異なるサイト間でWSFC構成を維持できません。
- ターゲットサーバーはすでに別のWSFC構成の一部であるため、WSFC構成のDRサイトでターゲットサーバーを利用することはできません。
- 目標復旧時点（RPO）と目標復旧時間（RTO）に関するサービスレベルアグリーメント（SLA）は、手動エラーからの迅速な復旧を強制します。これは、高可用性の1つのインスタンスでトランザクションログバックアップを復元する遅延復旧でのみ実現できます。 （HA）およびDR戦略。
したがって、ログ配布を使用して、現在のプライマリのメインサイトで実行されたバックアップからトランザクションログを送信することにより、DRサイトにあるターゲットサーバーを提供する必要があります。
ログ配布を設定する前に、次の前提条件を満たしていることを確認してください。
- プライマリデータベースは、完全ログまたは一括ログ回復モデルを使用する必要があります。データベースを単純回復に切り替えると、ログ配布が機能しなくなります。
- ログ配布を構成する前に、トランザクションログのバックアップをセカンダリサーバーで使用できるようにするための共有パスを作成する必要があります。
- ログ配布ストアドプロシージャには、sysadminfixedサーバーロールのメンバーシップが必要です。
- バックアップ共有パスには、SQLServerサービスアカウントへの読み取りおよび書き込み権限が必要です。
この例では、次の画像に示すように、PRIMEHEADと呼ばれるプライマリレプリカサーバーとHEAD2と呼ばれるセカンダリレプリカの間にAlwasyOnを既にセットアップしています。
このセクションでは、AlwaysOnAGの一部であるデータベースでログ配布を構成するためのステップバイステップのソリューションを提供します。
AdventureWork2014のログ配布を構成します PRIMEHEADとDRサーバーHEAD3の間のデータベース。
データベースでログ配布を構成するときに、 AdventureWork2014の完全バックアップを作成します LSCopyのログバックアップを保存するには、PRIMEHEADに共有フォルダを作成する必要があります。 （ログ配布）ジョブの使用。
データベースを右クリックし、プロパティを選択します 、[トランザクションログの送信]をクリックします PRIMEHEADの左側にあるオプション。次に、強調表示されたログ配布構成のプライマリデータベースとしてこれを有効にするをクリックします。 次の画像に示すチェックボックス：
バックアップ設定をクリックします LSバックアップを構成するには オプション。次の図に示すように、LSバックアップのネットワーク共有パスを選択します。
この時点で、要件に応じてLSバックアップをスケジュールすることもできます。ただし、このシナリオでは、デフォルト設定を使用します。
DRサーバーを追加するには、[追加]をクリックします 次の画像に示すように：
接続をクリックします 次の画像に示すように、DRサーバーであるHEAD3に接続するには：
セカンダリデータベースの初期化 データベースはHEAD3ですでに初期化されているため、タブで3番目のオプションを選択します。
ファイルのコピーをクリックします タブ。 コピーされたファイルの保存先フォルダ ボックスに、トランザクションログのバックアップがコピーされるパスを入力します。このシナリオでは、 C：\ LSCopyAlwaysOnを使用します 次の画像に示すように、パスの場合：
トランザクションログの復元 タブ、バックアップを復元するときのデータベースの状態 、リカバリモードなしのいずれかを選択します またはスタンバイモード 、次の画像に示すように：
この例では、リカバリモードなしを選択しました 、これは、DRデータベースにアクセスできないことを意味します。 スタンバイモードを選択した場合 、DRデータベースは、エンドユーザーが読み取り専用モードで使用できます。
OKをクリックします ログ配布を開始します。
次の画面が表示されます。
ログ配布ステータスを確認するには、DRサーバー、HEAD3、インスタンスを右クリックし、[レポート->標準レポート->トランザクションログ配布ステータス]を選択します。 。次の画面が表示された場合、ログ配布は正常であり、期待どおりに機能しています。
PRIMEHEADとHEAD2の間でAGフェイルオーバーが発生した場合、AG仕様を考慮して構成するまで、ログ配布は中断されます。
これで、HEAD2からHEAD3へのログ配布を構成できます。これにより、将来AGレプリカ間でフェイルオーバーが発生した場合でも、ログ配布機能に影響を与えることはありません。ログのバックアップは、プライマリとして機能しているレプリカに関係なく、常に同じパスまたは場所で実行されます。
レプリカ間でフェイルオーバーを開始する必要があります。フェイルオーバーを開始する前に、次の手順を実行してください。
-
プライマリレプリカでLSバックアップジョブを実行し、ジョブを無効にします。
-
セカンダリレプリカでLSコピーと復元ジョブを実行してから、無効にします。
これを行うには、AGを右クリックして、次の画像に示すようにフェイルオーバーオプションを選択します。
これは、次のT-SQLコマンドを使用してAGフェイルオーバーを手動でトリガーすることによっても実行できます。
USE master;
GO
ALTER AVAILABILITY GROUP [AGName] FAILOVER
GO
フェイルオーバーが完了すると、次のウィンドウが表示されます。
AGがPRIMEHEADとHEAD2の間でフェイルオーバーした後、現在のプライマリインスタンスはHEAD2です。
同じ手順に従って、現在のプライマリサーバーまたはノードHEAD2からDRサーバーHEAD3へのログ配布を構成します。ログ配布を構成するときに、PRIMEHEADとHEAD3の間でLS構成中に使用したものと同じ共有パスを選択します。 \ Available2017 \ lsbackup 。
現在のプライマリであるHEAD2とHEAD3の間のログ配布が完了すると、HEAD2にLSバックアップジョブが作成され、HEAD3に別のLSコピーおよびLS復元ジョブのセットが作成されます。
もう一度、AGレプリカ間のフェイルオーバーを開始します。フェイルオーバーを開始する前に、必ず次の手順を実行してください。
-
プライマリ（HEAD2）でLSバックアップジョブを実行し、ジョブを無効にします。
-
セカンダリ（HEAD3）でLSコピーおよび復元ジョブを実行してから、無効にします。
最後のフェイルオーバー後、現在のプライマリはPRIMEHEAD、HEAD2はセカンダリレプリカ、HEAD3はDRサーバーです。 LSバックアップジョブはサーバー（プライマリとセカンダリ）の両方に存在するため、PRIMEHEADとHEAD2の両方でLSバックアップジョブを変更して、現在のプライマリからのログバックアップのみを取得するようにする必要があります。
これを行うには、次のコードをジョブステップ1に追加します。
Declare @dbname as varchar(20)
Set @dbname=’AdventureWorks2014’
If sys.fn_hadr_backup_is_preferred_replica (@dbname)<>1
begin
RAISERROR (50005,-- Message id,
16, -- Severity,
1, --State,
N’This is not the primary server backup is rolled back’);
end
次の画像はこれを示しています：
上記の変更を行った後、LSバックアップジョブがセカンダリサーバーで失敗し始めますが、プライマリでは正常に実行されることに注意してください。
DRサーバーであるHEAD3には2セットのLSコピーおよびリストアジョブがあるため、一度に1セットのジョブのみが実行されるようにする必要があります。 HEAD2とHEAD3の間のログ配布を構成しているときに作成されたジョブを有効のままにし、他の一連のジョブを無効にする必要があります。
次の画像は詳細を示しています：
これで、AlwaysOnAGの既存の部分であるデータベースでログ配布を正常に構成できました。どのサーバーがプライマリサーバーとして機能しているかに関係なく、ログ配布は同期されます。
注 ：テストせずに本番環境に変更を加えないことを強くお勧めします。このソリューションを実稼働環境に実装する前に、まずこの構成をテスト環境に実装してください。
a）バックアップジョブが現在のプライマリレプリカで正常に実行されていることを確認します。b）バックアップパスは共有パスと同じである必要があります。c）HEAD2からHEAD3へのLS構成中に作成されたコピーおよび復元ジョブは正しく実行される必要があります。 DRサーバー上。d）標準レポートセクションでトランザクションログの出荷ステータスを確認します。
高可用性データベースでログ配布を構成すると、別のデータセンターにaDRサーバーをセットアップできます。この設定は、災害が発生した場合に役立ち、別のデータセンターのサーバーが影響を受けた場合でも、手作業を最小限に抑えながらビジネスに影響を与えません。
[フィードバック]タブを使用して、コメントを書き込んだり、質問したりします。
専門家による管理、管理、構成で環境を最適化する
Rackspaceのアプリケーションサービス（RAS） 専門家は、幅広いアプリケーションポートフォリオにわたって次の専門的かつ管理されたサービスを提供します。
- eコマースおよびデジタルエクスペリエンスプラットフォーム
- エンタープライズリソースプランニング（ERP）
- ビジネスインテリジェンス
- Salesforceの顧客関係管理（CRM）
- データベース
- メールホスティングと生産性
お届けします：
- 偏りのない専門知識 ：私たちは、即時の価値を提供する機能に焦点を当てて、お客様の近代化の旅を簡素化し、導きます。
- 狂信的な経験 ™：最初にプロセスを組み合わせます。テクノロジーセカンド。包括的なソリューションを提供するための専用のテクニカルサポートを備えたアプローチ。
- 比類のないポートフォリオ ：豊富なクラウドエクスペリエンスを適用して、適切なテクノロジーを適切なクラウドに選択して導入できるようにします。
- アジャイルデリバリー ：私たちはあなたがあなたの旅の途中であなたに会い、あなたの成功と一致します。
今すぐチャットして始めましょう。
-
MicrosoftSQLServerの高度な破損と回復
このブログでは、Microsoft®SQLServer®のデータベースレベルで発生する可能性のある破損、それらを検出する方法、および高度な復元と修復の手法を使用してそれらを修正する方法について説明しています。 はじめに 現在、SQL Serverは、その高度な内部構造と優れた信頼性により、最も一般的で広く使用されているリレーショナルデータベース管理システムの1つです。多くの組織は、重要なビジネスデータを維持および保存するためにSQLServerデータベースを選択しています。 企業は、データベース管理者（DBA）がデータベースのパフォーマンス、保守、およびセキュリティを継続的に改善することを
-
統合データプラットフォーム：SQL Server 2019
2006年、英国の数学者Clive Robert Humbyは、「データは新しい石油です」という言葉をマークしました。それ以来、ITリーダーはこれを繰り返し聞き、アイデアに共感し、あらゆる段階で拡張編集を行ってきました。 クライブはさらに次のように付け加えました。「データは価値がありますが、洗練されていないと実際には使用できません。収益性の高い活動を推進する価値のあるエンティティを作成するには、wayOilをガス、プラスチック、化学薬品などに変更する必要があります。そのため、データに価値を持たせるには、データを分析して分析する必要があります。」 ITリーダーはこれ以上同意できず、データから