Managed Instance リンクのベストプラクティス - Azure SQL Managed Instance
適用対象: 
Azure SQL Managed Instance
この記事では、Azure SQL Managed Instance 用のリンク機能を使用する場合のベスト プラクティスの概要を説明します。 Azure SQL Managed Instance 用のリンク機能では、任意の場所にホストされている SQL サーバーを SQL Managed Instance に接続して、クラウドにほぼリアルタイムのデータ レプリケーションを提供します。
注意
リンクの一部の機能は一般提供されていますが、一部は現在プレビュー段階です。 詳細については、前提条件に関する記事を参照してください。
定期的にログのバックアップを作成する
SQL Server が初期プライマリである場合は、初期シード処理が完了した後、つつまり Azure SQL Managed Instance 上のデータベースが "復元中..." の状態でなくなったときに、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 を使用したトランザクション ログ エラーのトラブルシューティング」を参照してください。
Note
リンクに参加すると、プライマリ レプリカであるかどうかに関係なく、SQL Managed Instance 上で自動完全バックアップとトランザクション ログ バックアップが実行されます。 差分バックアップは実行されないため、復元時間が長くなる可能性があります。
レプリカ間でパフォーマンスキャパシティを一致させる
リンク機能を使用しており、セカンダリ レプリカがプライマリ レプリカからのレプリケーションやフェールオーバー後に対応できない場合は、パフォーマンスの問題を回避するために、SQL Server と SQL Managed Instance の間でパフォーマンス キャパシティを一致させることが重要です。 パフォーマンス キャパシティには、CPU コア (または Azure の仮想コア)、メモリ、I/O スループットが含まれます。
セカンダリ レプリカの再実行キューのサイズを使用して、レプリケーションのパフォーマンスをチェックできます。 再実行キューのサイズは、セカンダリ レプリカでの再実行を待機しているログ レコードの数を示します。 再実行キューのサイズが常に高い場合は、セカンダリ レプリカがプライマリ レプリカに対応できないことを示します。 再実行キューのサイズは、次の方法で確認できます。
- プライマリ レプリカの sys.dm_hadr_database_replica_states 動的管理ビューにある
redo_queue_size値。 - プライマリ レプリカの Get-AzSqlInstanceLink にある
InstanceRedoLagReplicationSeconds値。
再実行キューのサイズが常に高い場合は、セカンダリ レプリカのリソースを増やすことをご検討ください。
証明書のローテーション
データベース ミラーリング エンドポイントのセキュリティ保護に使用する証明書の有効期限が切れる可能性があり、その結果、リンク品質が低下する可能性があります。 この問題を回避するには、有効期限が切れる前に証明書をローテーションします。
次の Transact-SQL (T-SQL) コマンドを使用して、現在の証明書の有効期限を確認します。
-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'
証明書の有効期限が近づいている、または既に有効期限が切れている場合は、新しい証明書を作成し、既存のエンドポイントを変更して、現在の証明書を置き換えることができます。
新しい証明書を使用するようにエンドポイントが構成されたら、期限切れの証明書を削除できます。
起動時のトレース フラグを追加する
SQL Server には 2 種類のトレース フラグ (-T1800 と -T9567) があります。これらを起動時のパラメーターとして追加すると、リンク経由のデータ レプリケーションのパフォーマンスを最適化できます。 詳細については、「起動時のトレース フラグを有効にする」を参照してください。