まえがき
多くの場合、MS SQL Server DBMSのフォールトトレランスを確保するという問題に対処できます。 エンタープライズライセンスがなく、スタンダードのみの場合はさらに興味深いものになります。
このインスタンスには大きな制限があるため、Expressライセンスは考慮されないことに注意してください。 はい、一部は回避できます。 たとえば、10 GBのデータベースの最大サイズは、大きなデータベースを小さなデータベースに分解することで簡単に解決できます(たとえば、何らかの理由で新しいデータベースを作成し、メインデータベース内の異なるデータベースの同じテーブルのサンプルを結合する場合)。 ただし、Expressのフォールトトレランスは、システム管理者または独自の(またはサードパーティの)ソフトウェアを使用して実現されます。
この記事では、MS SQL Server 2017のすべての既存の標準フォールトトレランステクノロジを簡単に分析し、標準ライセンスで最も適切な統合されたものの障害実装の例を検討します。
短いレビュー
- AlwaysOn:すべての参加者間の負荷分散。すべての参加者は、その特性に応じてできるだけ類似している必要があります。
同期モードでは、データ伝送の最大の信頼性が保証されますが、動作速度は最も遅い参加者の速度と等しくなります。 非同期モードでは、最大のパフォーマンスが提供されますが、参加者間でデータの不整合が発生する可能性があり、より複雑なサポートにつながり、メイン参加者に障害が発生した場合に最新の変更が失われる可能性があります。
同期モードでの切り替え速度はほぼ瞬時であり、システム管理者とDBAの介入を必要としません。非同期モードでは、DBの現在の状態に依存しますが、通常は平均5分までです(システム管理者の関与なしに1人のDBAによる切り替えを自動化することも可能です)。
データベースの推奨テクノロジーとしてマイクロソフトによって認識されています。 2012バージョン以降のエンタープライズライセンスで利用可能。 標準ライセンスで制限付きで利用できます(詳細については、 基本的な可用性グループに関する上位5つの質問を参照してください)。
- クラスタリング:構成が簡単であるにもかかわらず、このソリューションはすべてのデータウェアハウスという単一の形式のボトルネックにより信頼性が低くなります。 データウェアハウスに障害が発生した場合、回復にはかなり長い時間がかかります(1時間以上)。
2008バージョン以降の標準ライセンスで利用可能。
- レプリケーション:レプリケーションには、各メンバーテーブルのシステムトリガーの作成が含まれ、スナップショットのレプリケーションはメインデータベースに非常に大きな負荷をかけます。 したがって、スナップショットのレプリケーションは、データベースの最小負荷時間(夜間など)でのみ実行できます。これは、ホットリザーブが必要なため、受け入れられません。 マージレプリケーションは、一部のシステム(CRM、NAVなど)では維持が難しく、データベース構造が頻繁に変更されるため、1Cには適していません。
トランザクションレプリケーションは可能ですが、エンタープライズライセンスが必要です。
2008バージョンまでの標準(マージおよびデータベーススナップショット)およびエンタープライズ(トランザクション)ライセンスで利用可能。
- ミラーリング:すべてのモードで可能ですが、AlwaysOnと同様に、同期モードは最大の信頼性と高速スイッチングを提供し、非同期モードはメインデータベースとの最大速度を提供しますが、すべての参加者間でデータの不整合が発生する可能性があり、スイッチングは瞬時には行われません。 ここでは、データベースレベルで切り替えると、ミラーリング監視サーバー(たとえば、メインサーバーで50%を超えるCPU負荷)またはDBAツールが自動的に提供されます。 別のサーバーへの接続は、システム管理者によって提供されます。 あらゆるタイプのミラーリングのバックアップデータベースは連続リカバリモードであるため、そのデータベースにアクセスすることはできません。
DB復旧モードがいっぱいです。
マイクロソフトは、時代遅れのデータベーステクノロジを認識しました。
2008バージョン以降の標準(同期モード)およびエンタープライズ(非同期モード)ライセンスで利用可能です。
- トランザクションログの配信: 2つのモードがあります-バックアップサーバーでの永続的な復旧または遅延のある復旧。
最初のモードは、バックアップデータベースを(ミラーリングの場合と同様に)連続リカバリモードに転送し、アクセスすることはできません。
2番目のモードは、ローリング更新時に定期的にバックアップデータベースを回復モードにします(ローリング更新の間、バックアップデータベースは使用可能ですが、MS SQL Serverのインスタンスが同じバージョンである場合は可能です)。
操作の原理は簡単です:
- 定期的に、データベーストランザクションログのバックアップコピーがソース上でソースとバックアップ頬骨の両方のパブリックフォルダーに作成されます(パスとスケジュールはデフォルトで15分ごとに構成されます)。
- バックアップ頬骨は、データベーストランザクションログの結果のバックアップコピーを定期的にローカルのアクセス可能なフォルダー内にコピーします(パスとスケジュールはデフォルトで15分ごとに構成されます)。
- バックアップ頬骨は、トランザクションログのコピーされたバックアップからトランザクションログを復元します(デフォルトでは、スケジュールは15分ごとに構成されます)。
切り替えは、DBA DBAレベル、およびサーバー接続レベル、システム管理者レベルで自動化できます。
また、このメソッドは常に非同期モードで機能することに注意してください。 複数のバックアップデータベースを構成できます。
DBリカバリモード-完全または不完全なロギング
2008バージョン以降の標準ライセンスで利用可能。
おわりに
上記のオプションから、標準ライセンスでのトランザクションログの配信の方が適しています。これは、1つのサーバーから別のサーバーへのスムーズな移行(環境の更新時など)に使用すると便利だからです。 また、トランザクションログの配信は保守が非常に簡単で、作業も簡単です。また、常に非同期モードで動作します(非同期ミラーリングモードほどデータベースはロードされません)。 いずれの場合でも、独自の自動切り替えを構成できる場合、ミラーリングは許容されます。そうでない場合、たとえば、メインサーバーのCPUの負荷が50%を超える場合、誤った切り替えが可能です。
企業向け-AlwaysOnテクノロジは明確に提供されています。
トランザクションログ配信フェールオーバーの構成
トランザクションログ配信の構成の詳細については、
ここで説明し
ます 。 また、このプロセスは、繰り返し使用するための独自のユーティリティを作成することで自動化できます。また、障害が発生した場合は、修正後にメインサーバーに戻ります。
ここで、DBMSレベルでトランザクションログを配信する際のフェールオーバーの可能なオプションの1つを分析します。
この方法は、MS SQL Serverの1つのインスタンスのみのバックアップであるサーバーにのみ適していることに注意することが重要です。
最初に、アクションのシーケンスについて説明します。
- ソースから最新のファイルをコピーする際にすべてのタスクを実行します(よく考えられたアーキテクチャにより、メインサーバーがクラッシュしてもパスにアクセスできるはずです)
- ソースからファイルをコピーするためのすべてのタスクをオフにします
- すべてのタスクを実行して、ソースの最新ファイルからデータベースを復元します
- すべてのタスクをオフにして、ソースからの最新ファイルからデータベースを復元します
- データベースを復元し、ジャーナル配信の基本とするが、受信者はいない
- データベースの完全バックアップを作成する
- データベーストランザクションログのバックアップコピーを作成するためのタスクを作成する
以下は、ストアドプロシージャの形式での上記のシーケンスの実装例です。
トランザクションログのバックアップコピーを作成するには、作成されたタスクを起動するログイン(できればドメイン)を構成することが重要であることに注意してください。
トランザクションログ配信フェールオーバーの実装例CREATE PROCEDURE [srv].[RunLogShippingFailover] @isfailover bit=1, @login nvarchar(255)=N'',
メインサーバーに戻るには、バックアップサーバーからメインサーバーへのトランザクションログの配信を再構成してから、フェールオーバーを実行する必要があります(その後、メインサーバーが再び動作可能になります)。 その後、戦闘サーバーからバックアップへのトランザクションログの配信を構成します。
トランザクションログ監視配信の自動修正の構成
トランザクションログの配信を監視するには、モニターサーバーでLSAlert_ <NAME_INSTALL>タスクとレポートを使用します(モニターサーバーインスタンスを右クリックします。以下、レポート\標準レポート\トランザクションログ配信ステータスと呼びます)。
時間の経過とともに、サーバーモニター(戦闘サーバーではない場合)が、戦闘サーバーでデータベーストランザクションログのバックアップコピーを作成するのに誤って最後に時間がかかることがよくあります。 その結果、誤った警告が発生します。
次の簡単なスクリプトで問題を解決できます。
トランザクションログの配信を監視するための修正の実装例 CREATE PROCEDURE [srv].[AutoCorrectMonitorLogShipping] AS BEGIN SET NOCOUNT ON; update t2 set t2.[last_backup_date]=t1.[BackupFinishDate] ,t2.[last_backup_date_utc]=DateAdd(hour,-DateDiff(hour,GetUTCDate(),GetDate()),t1.[BackupFinishDate]) ,t2.[last_backup_file]= RIGHT(t1.[PhysicalDeviceName], CHARINDEX('\',REVERSE(t1.[PhysicalDeviceName]),1)-1) from [__].[SRV].[inf].[vServerLastBackupDB] as t1 inner join [msdb].[dbo].[log_shipping_monitor_primary] as t2 on t1.[DBName] collate SQL_Latin1_General_CP1_CI_AS=t2.[primary_database] collate SQL_Latin1_General_CP1_CI_AS where t1.[BackupType]=N'log'; END
ストアドプロシージャコールは、時間の経過とともに自動化できます。 たとえば、5分ごとに、対応するタスクをエージェントに作成します。 当然、バトルサーバーはバックアップ(サーバーオブジェクト\リンクサーバー)に接続する必要があります。
ここでは、最新のデータベースバックアップを定義するSRVデータベースの[inf]。[VServerLastBackupDB]ビューを使用します。
VServerLastBackupDBビューの実装例 CREATE VIEW [inf].[vServerLastBackupDB] as with backup_cte as ( select bs.[database_name], backup_type = case bs.[type] when 'D' then 'database' when 'L' then 'log' when 'I' then 'differential' else 'other' end, bs.[first_lsn], bs.[last_lsn], bs.[backup_start_date], bs.[backup_finish_date], cast(bs.[backup_size] as decimal(18,3))/1024/1024 as BackupSizeMb, rownum = row_number() over ( partition by bs.[database_name], type order by bs.[backup_finish_date] desc ), LogicalDeviceName = bmf.[logical_device_name], PhysicalDeviceName = bmf.[physical_device_name], bs.[server_name], bs.[user_name] FROM msdb.dbo.backupset bs INNER JOIN msdb.dbo.backupmediafamily bmf ON [bs].[media_set_id] = [bmf].[media_set_id] ) select [server_name] as [ServerName], [database_name] as [DBName], [user_name] as [USerName], [backup_type] as [BackupType], [backup_start_date] as [BackupStartDate], [backup_finish_date] as [BackupFinishDate], [BackupSizeMb],
結果
この記事では、MS SQL Server 2017のフォールトトレランスとクイックアベイラビリティについて考えられるすべてのオプションの概要を概説し、フェールオーバーの実装例とトランザクションログ配信監視の自動修正の例を分析しました。
謝辞
AlwaysOnについて建設的なコメントを寄せてくれた
NoOneに感謝します。
ソース:
»
Msdb»
SQL Server 2017エディションの比較»
AlwaysOn»
クラスタリング»
レプリケーション»
ミラーリング»
トランザクションログの配信»
ログ配布を構成する»
SQL Serverデータベースが最後に復元されたのはいつですか»
基本的な可用性グループに関する5つの質問