Managed Instance のリンクに関する最適手法 - Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

この記事では、Managed Instance リンクを使用して、Azure SQL Managed Instance と任意の場所でホストされている SQL Server インスタンスの間でデータをレプリケートするためのベスト プラクティスについて説明します。 リンクは、リンクされたレプリカ間のほぼリアルタイムのデータ レプリケーションを提供します。

定期的にログのバックアップを作成する

SQL Serverが初期プライマリの場合、最初のシード処理が完了し、データベースがAzure SQL Managed Instance上でRestoring...状態でなくなった後に、SQL Serverで初回のログバックアップを実行します。 次にSQL Serverトランザクション ログ バックアップを定期的に実行しトランザクション ログ ファイルのサイズを正常に保ち、SQL Serverがプライマリ ロールにある間は正常な状態に保ちます。

リンク機能は、Always On 可用性グループに基づく 分散型可用性グループ テクノロジを使用してデータをレプリケートします。 分散型可用性グループのデータ レプリケーションは、トランザクション ログ レコードのレプリケートに基づいています。 プライマリ SQL Server インスタンスは、セカンダリ レプリカ上のデータベースにレプリケートされるまで、データベースからトランザクション ログ レコードを切り捨てることはできません。 ネットワーク接続の問題によってトランザクション ログ レコードのレプリケーションが遅くなったりブロックされたりした場合、ログ ファイルはプライマリ インスタンスで増加し続けます。 ワークロードの強度とネットワーク速度によって、増加速度が決まります。 ネットワーク接続の停止が長引き、プライマリ インスタンスのワークロードが重い場合、ログ ファイルは使用可能なすべての記憶域を使用できます。

定期的なトランザクション ログ バックアップを実行すると、トランザクション ログが切り捨てられ、ログ ファイルの増加によりプライマリ SQL Server インスタンスの領域が不足するリスクが最小限に抑えられます。 ログ バックアップは既に自動的に実行されるため、SQL Managed Instanceがプライマリである場合は、追加のアクションは必要ありません。 SQL Server プライマリでログ バックアップを定期的に実行することで、計画外のログ増加イベントに対するデータベースの回復性を高めることができます。 SQL Server エージェント ジョブを使用して、毎日のログ バックアップ タスクをスケジュールすることを検討してください。

Transact-SQL (T-SQL) スクリプトを使用して、このセクションで提供されているサンプルなどのログ ファイルをバックアップできます。 サンプル スクリプト内のプレースホルダーは、お使いのデータベースの名前、バックアップ ファイルの名前とパス、説明に置き換えてください。

トランザクション ログをバックアップするには、SQL Serverで次のサンプル Transact-SQL (T-SQL) スクリプトを使用します。

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

次の Transact-SQL (T-SQL) コマンドを使用して、SQL Serverでデータベースで使用されているログ領域を確認します。

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

クエリ出力は、サンプル データベース tpcc の次の例のようになります。

この例では、データベースは使用可能なログのうち 76% を使用しており、ログ ファイルの絶対サイズは約 27 GB (27,971 MB) となっています。 アクションのしきい値は、ワークロードによって異なります。 前の例では、トランザクション ログのサイズとログの使用率は、通常、ログ ファイルを切り捨てて空き領域を増やすためにトランザクション ログ バックアップを実行する必要があることを示しています。または、ログ バックアップを頻繁に実行する必要があります。 また、トランザクション ログの切り捨てが、開いているトランザクションによってブロックされていることを示している可能性もあります。 SQL Serverでのトランザクション ログのトラブルシューティングの詳細については、「完全なトランザクション ログ (SQL Server エラー 9002)を参照してください。 Azure SQL Managed Instanceでのトランザクション ログのトラブルシューティングの詳細については、「トランザクション ログエラーをAzure SQL Managed Instanceでトラブルシューティングする」を参照してください。

レプリカ間でパフォーマンスキャパシティを一致させる

リンク機能を使用する場合は、SQL ServerとSQL Managed Instanceのパフォーマンス容量を一致させます。 この照合は、セカンダリ レプリカがプライマリ レプリカからのレプリケーションやフェールオーバー後に対応できない場合に、パフォーマンスの問題を回避するのに役立ちます。 パフォーマンス容量には、CPU コア (または Azure 内の仮想コア)、メモリ、および I/O スループットが含まれます。

セカンダリ レプリカの再実行キュー サイズを確認することで、レプリケーションのパフォーマンスを監視できます。 再実行キューのサイズは、セカンダリ レプリカでの再実行を待機しているログ レコードの数を示します。 再実行キューのサイズが一貫して高い場合、セカンダリ レプリカがプライマリ レプリカに対応できないことが示されます。 再実行キューのサイズは、次の方法で確認できます。

• プライマリ レプリカの動的管理ビュー sys.dm_hadr_database_replica_states にある redo_queue_size 値。
• プライマリ レプリカの Get-AzSqlInstanceLink 内にある InstanceRedoLagReplicationSeconds 値。

再実行キューのサイズが常に高い場合は、セカンダリ レプリカのリソースを増やすことをご検討ください。

レプリケーションのラグを監視する

レプリケーションラグの監視は、セカンダリ レプリカがプライマリ レプリカと同期する速度を判断するのに役立ちます。 大きな不一致は、セカンダリ レプリカがプライマリ レプリカに追いつくのに問題があることを示しています。これは通常、2 つのインスタンス間のリンクでのネットワーク スループットの低下、2 つのレプリカ間のリソース割り当ての不一致、またはプライマリ レプリカのワークロードが過度に高いことが原因です。

レプリケーションの遅延の監視は、計画されたフェールオーバーを実行する場合に特に重要です。そのため、フェールオーバーを実行する前に、セカンダリ レプリカをプライマリ レプリカと完全に同期する必要があります。 レプリケーションのラグが大きい場合、フェールオーバーの完了に時間がかかる場合があり、場合によっては失敗する場合もあります。

レプリカ間のレプリケーションのラグを監視するには、SQL ServerとSQL Managed Instanceの両方で次の T-SQL クエリを使用します。

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

証明書のローテーション

SQL Serverでデータベース ミラーリング エンドポイントをセキュリティで保護するために使用する証明書を手動でローテーションすることが必要になる場合があります。 サービスは、SQL Managed Instance上のデータベース ミラーリング エンドポイントをセキュリティで保護するために使用される証明書を管理し、自動的にローテーションするため、手動でローテーションする必要はありません。

SQL Server

SQL Serverでデータベース ミラーリング エンドポイントをセキュリティで保護するために使用する証明書の有効期限が切れる可能性があります。 証明書の有効期限が切れると、リンクが低下する可能性があります。 この問題を回避するには、有効期限が切れる前 に証明書をローテーション します。

現在の証明書の有効期限を確認するには、次のTransact-SQL (T-SQL) コマンドを使用します。

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 

証明書の有効期限が近づいている場合、または既に有効期限が切れている場合は、 新しい証明書を作成し、既存のエンドポイントを変更して 現在の証明書を置き換えます。

新しい証明書を使用するようにエンドポイントを構成した後、期限切れの証明書を 削除 できます。

SQL マネージド インスタンス

SQL Managed Instance上のデータベース ミラーリング エンドポイント証明書は、定期的に自動的にローテーションされます。 SQL Managed Instance でデータベース ミラーリング エンドポイント証明書の有効期限を監視する必要はありません。SQL Server で証明書チェーンを正常に検証できる限り。

SQL Serverで証明書チェーンを検証する

証明書チェーンに関する問題により、リンクが低下する可能性があります。 この問題を回避するには、SQL Serverで証明書チェーンを定期的に検証します。

次のシナリオでは、SQL Serverの証明書チェーンに問題が発生する可能性があります。

• SQL Managed Instanceでのスケジュールされた証明書のローテーション。
• データベース ミラーリング エンドポイントのセキュリティ保護に使用する証明書の削除や変更など、SQL Server上の証明書に対する意図しない変更や偶発的な変更。

まず、インポートされた MI エンドポイント証明書のcertificate_idを確認し、<ManagedInstanceFQDN> の値を置き換えてから、SQL Serverで次のクエリを実行します。

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

次に、前のクエリの結果から <certificate_id> の値を置き換え、SQL Serverで次のクエリを実行して、証明書を検証します。

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Commands completed successfully. Completion time: ...の応答は、MI エンドポイント証明書が正常に検証されたことを示します。

エラーが発生した場合、最も信頼性の高い対策は、まずセクション「証明書の公開キーをSQL Managed Instanceから取得し、SQL Serverにインポートする」と「Azureの信頼されたルート証明機関の鍵をSQL Serverにインポートする」で作成されたすべての証明書を削除し、その後それらを再インポートすることで証明書チェーンを復元することです。

起動時のトレース フラグを追加する

SQL Serverには、2 つのトレース フラグ (-T1800 と -T9567) があり、スタートアップ パラメーターとして追加すると、リンクを介してデータ レプリケーションのパフォーマンスを最適化できます。 詳細については、「起動時のトレース フラグを有効にする」を参照してください。

同期コミットを慎重に使用する

リンクの既定のコミット モードは非同期です。 コミット モードを同期モードに変更することは可能ですが、推奨されず、潜在的なデータ損失から保護する必要はありません。

計画されたリンクされたフェールオーバー中、レプリケーションはフェールオーバーが完了するまで一時的に同期コミット モードに切り替わります。 フェールオーバー後、コミット モードは、フェールオーバー前に同期コミット モードに明示的に設定されている場合でも、非同期に切り替わります。

リンクに同期コミット モードを使用すると、特にレプリカ間のネットワーク待機時間が長い場合に、プライマリ レプリカのパフォーマンスに影響を与える可能性があります。 同期コミット モードでは、プライマリ レプリカ上のトランザクションは、プライマリでトランザクションをコミットする前に、セカンダリ レプリカでトランザクション ログ レコードが書き込まれたことを確認するまで待機する必要があります。 この待機時間は、ネットワーク待機時間が長いほど長くなり、トランザクションの応答時間が長くなり、プライマリ レプリカのスループットが低下する可能性があります。

関連するコンテンツ

リンクの使用については、以下を参照してください。

• Managed Instance リンクの準備環境
• SSMS
• スクリプトを使用してSQL Serverと SQL Managed Instance 間のリンクを構成します
• リンクをフェールオーバーする
• リンクを使用して移行する
• リンク に関する問題のトラブルシューティング

リンクの詳細については、次を参照してください。

• Managed Instance リンクの概要
• Managed Instance リンクを使用したディザスタリカバリ
• リンク を維持するためのベスト プラクティス

他のレプリケーションや移行のシナリオについては、以下を検討してください。

• SQL Managed Instance でのトランザクション レプリケーション
• ログ再生サービス (LRS)