適用対象:
Azure SQL データベース
MicrosoftはAzure SQL Databaseのデータ整合性管理を担当しています。 従来のDBAによるSQL Serverのデータ整合性監視やデータベース破損からの回復技術は存在しますが、MicrosoftのSQLエンジニアリングチームは、一部の破損クラスを自動かつデータ損失なしに処理する新しい技術を開発しました。 サービスは、可能な限りデータ損失やダウンタイムを避けるためにこれらの技術を用いています。
この記事では、これらの技術の一部、その仕組み、そしてAzure SQL Databaseでデータを保護するために取るべきステップについて懸念する顧客にどのような影響を与えるかを概説します。
Microsoftがデータ整合性を管理する方法
Azure SQL Databaseのデータ整合性を保護するには、複数の技術と進化する手法の組み合わせが必要です。
広範なデータ整合性エラーアラート監視。 SQL データベース エンジンは、データの整合性に関する懸念を示すすべてのエラーや未処理の例外に対してアラートを発行します。 エンジニアリングチームはこれらのアラートを処理・調査しています。
I/Oシステムの「書き込み喪失」検出。 データベースエンジンは、物理的な破損問題の最も一般的な原因であるI/Oシステムの「書き込み喪失」を検出する追加機能を備えています。 この機能はページ書き込みとそれに関連するLSN(ログシーケンス番号)を追跡します。 ディスクからのデータページの後続の読み取りは、そのページの期待されるLSNと比較されます。 もしLSNにディスク上のものと期待されるものと不一致があると、そのページは古くなり、エンジニアリングチームに即座に警告が届きます。
自動ページ修復。 一部のサービス層では、事業継続性の目的でデータベースのレプリカが提供されています。 サービスは自動ページ修復を活用しており、これは可用性グループで使われる技術に似ています。 もしレプリカがデータの整合性の問題でページを読み取れない場合、サービスは別のレプリカから新しいページのコピーを取得し、データの損失や顧客のダウンタイムなしに読み取れないページを置き換えます。
保存時および転送時のデータ整合性 サービス内のすべてのデータベースは、
CHECKSUM設定を使ってページ検証を行うように設定されており、この設定はページ全体のチェックサムを計算し、読み取り時に検証するためにページヘッダーに保存します。 トランスポート層セキュリティ(TLS)は、TCP/IPが提供する基本的なトランスポートレベルのチェックサムに加え、すべての通信にも使用されます。バックアップと復元の整合性チェック。 Azure SQL Databaseはサービス管理バックアップ中および各復元操作中の両方でページ検証を行います。 問題が見つかれば、直ちにエンジニアリングチームに通知されます。
Microsoftがデータインテグリティインシデントをどのように扱うか
Microsoftは誤った結果や破損の事案を最も深刻に扱います。 同社はすべてのAzureエンジニアリングチームから24×365年体制のサポートを提供しています。 インテグリティインシデントを扱う際の目標は、利用不可を最小限に抑え、データ損失の量を最小限に抑えることです。
システムデータの整合性問題
Microsoftは顧客データやデータベースの可用性に影響しない問題を、顧客に通知せずに修正します。 例としては、自動ページ修復で解決できる問題や、顧客データやクエリ結果に影響を与えない内部データベースのメタデータやテレメトリの破損などがあります。
顧客データの整合性問題
Microsoftが誤った結果や顧客データ破損の問題を検出した場合、Microsoftは以下の措置を講じます。
- プライバシー法を遵守し、検出が確認された直後にできるだけ早く顧客に連絡を取るよう最善を尽くします。
- 連絡が取れた場合は、顧客と直接連携し、破損の範囲を説明し、回復オプションを説明し、顧客が自分の用途やシナリオに最適な選択肢を選べるようにします。
- 可能な限り、顧客がアプリケーションへの影響範囲を理解するのを支援します。例えば、データの破損によって他のデータが予期せぬ形で変更されたかどうかを特定します。
Microsoftは顧客と連携して様々な方法や手順を用いてデータの破損を修復します。 顧客の承認なしにデータ損失を引き起こす可能性のある修復は試みません。 顧客はAzure SQL DatabaseでDBCC CHECKDB修理オプションを行うことができません。なぜなら、SINGLE_USERモードでデータベースを配置できないからです。 しかし、Microsoft SQLチームは以下の修復措置を取ることができますが、これに限定されません。
- インデックスを再構築します。 例えば、ベーステーブルが破損していない非クラスタインデックスを再構築します。
- 修復でデータ損失の可能性がない場合は、
REPAIR_REBUILDを使用してDBCC CHECKDBを実行してください。 - 修復によって一部のデータが失われる可能性がある場合は、
REPAIR_ALLOW_DATA_LOSSを指定してDBCC CHECKDBを実行します。 -
DBCC CHECKDBでデータ整合性問題を修復できない場合、エンジニアはデータ整合性問題が発生する前のポイントインタイム復元を行い、その後トランザクションログから関連トランザクションを手動で再生することがあります。 この手法が適用される例としては、取引ログが破損し、すべての取引の自動再生を妨げる一方で顧客データが破損しない場合があります。
エンジニアリングチームは、誤った結果やデータの破損につながる問題について詳細な事後分析を行います。 チームは問題によって作成された修理項目を綿密に追跡しています。 これらの事後分析は、前述の「書き込み消失」機能を含む、多くの重要な改善につながりました。
顧客主導の整合性チェック
サービスが提供する既存の監視と保護に加え、ユーザー主導の整合性チェックを追加の保護層として実行することも可能です。 例えば、このコマンドがあるデータベースの提供物で手動で DBCC CHECKDB を実行することができます。
Azure SQL Database HyperscaleではDBCC CHECKTABLE ('<TableName>') WITH TABLOCKを使いましょう。
顧客からのフィードバックと進化する手法
Azure SQLエンジニアリングチームは、サービスのデータ整合性問題検出機能を定期的に見直し、強化しています。 データ整合性エラーは稀ですが、Azureサポートからの通知を受け取る前にエラーが発生した場合は、サポートケースを提出してください。
もしMicrosoftのデータ整合性戦略についてフィードバックがあれば、エンジニアリングチームはぜひご連絡ください。 この件についてフィードバックやコメントをエンジニアリング チームに送るには、https://aka.ms/sqlfeedbackをご覧ください。 皆様のフィードバックは、Microsoftが既存の改善や新たなデータ整合性保護機能を開発するのに役立ちます。