Compute Engine で MySQL を構成する

Compute Engine には、MySQL データベースからのデータの読み取りと書き込みに使用できるさまざまなインスタンス タイプとストレージ オプションが用意されています。データベース ワークロードで最適なパフォーマンスとコストを実現するには、新世代の Infrastructure as a Service（IaaS）プロダクトで実行することをおすすめします。

次の構成に関する推奨事項では、MySQL ワークロードがオンライン トランザクション処理（OLTP）や一般的なウェブ アプリケーションをサポートするデータベースなど、読み取り負荷の高いシステムでよく使用されることを考慮しています。また、MySQL のバージョン 8.0 以降の使用や InnoDB ストレージ エンジンの使用など、一般的な構成の選択肢も考慮しています。パフォーマンス重視のワークロードでは、構成を調整して適合させる必要がある場合があります。このガイドをデプロイの出発点として、実際のワークロードでテストを行い、構成がニーズを満たしていることを検証することをおすすめします。

仮想マシン（VM）を選択する

MySQL ワークロードには、最新世代の C マシン ファミリーと N マシン ファミリーを使用することをおすすめします。これらのマシン ファミリーには、ほとんどの MySQL 構成で適切に動作するシェイプが含まれています。これらのマシンシリーズの概要については、次の Google Cloud ブログ投稿をご覧ください。これらのマシン ファミリーは Titanium を使用し、最新世代の Intel、AMD、Axion プロセッサをベースにしています。

パフォーマンス重視

ビジネスに不可欠な MySQL データベースなど、パフォーマンスが重要なワークロードには、リージョンで利用可能な場合は最新の C4 インスタンスと C4A インスタンスをおすすめします。アクセスできない場合は、C3 インスタンスと C3D インスタンスで同様のパフォーマンスを実現できます。

これらのインスタンスは、計算依存型のオペレーションで最も低く、最も一貫したレイテンシを実現します。また、パフォーマンス重視のワークロードに役立つ次の機能が含まれています。

  • 事前通知によるホスト メンテナンス イベントの制御
  • シングルコア ターボブーストの制御によるパフォーマンスの安定性の向上
  • ネットワーク帯域幅を増やすための Tier_1 ネットワーキング

C4A、C3、C3D インスタンスを使用している場合は、ローカル ソリッド ステート ドライブ（ローカル SSD）を使用して特定のパフォーマンス要件を満たすこともできます。

費用の最適化

トラフィックが少ないか中程度の MySQL データベースや、テスト環境または開発環境で使用されるデータベースなど、コストの最適化が最優先のワークロードには、最新の N4 インスタンスの使用をおすすめします。これらのインスタンスは、Compute Engine の次世代の動的リソース管理を使用します。C4、C4A、C3、C3D が提供する強力な保証はありませんが、堅牢なパフォーマンスを維持しながら総費用を最適化します。詳細については、次世代の動的リソース管理をご覧ください。

VM のサイズを構成する

使用する VM では、MySQL パフォーマンスの目標レベルに適した VM サイズを選択することが重要です。

1 秒あたりの書き込みトランザクション数（TPS）の高いパフォーマンスを目指す場合は、ブロック ストレージを主な検討要素とします。詳細については、このページのブロック ストレージを構成するをご覧ください。

読み取り秒間クエリ数（QPS）のパフォーマンスを向上させるには、MySQL の RAM ベースのバッファプールを使用してホットデータをキャッシュに保存し、ディスク アクセスを減らすことを強くおすすめします。これらのメリットを最大限に活用するには、次のことを行います。

  • ワーキング セット（データベースが一度に処理するデータの合計量）がバッファプールに収まるように、VM サイズを選択します。
  • VM の RAM の大部分を使用するようにバッファプールのサイズを設定します。

このような VM のサイズ設定の費用を最小限に抑えるには、RAM と仮想 CPU（vCPU）の比率が高い VM を使用し、未使用の vCPU に対して料金を支払わないようにすることをおすすめします。

ほとんどの MySQL ワークロードに最適なバランスを実現するには、ワークロードのワーキング セットを特定し、そのワーキング セットを RAM に収める最小の highmem インスタンス シェイプを選択します。highmem インスタンス シェイプには、vCPU ごとに約 8 GB の RAM が割り当てられます。これにより、大きなワーキング セットをキャッシュに保存するのに十分なメモリを確保しながら、高いクエリ負荷を処理するのに十分な CPU を維持できます。

ワーキング セットは大きいが、クエリ率が低いワークロードの場合は、N4 インスタンスを使用します。拡張メモリを備えたカスタム マシンタイプを使用して RAM 対 vCPU 比を高めることで、総費用をさらに最適化できます。

VM のネットワーク帯域幅を構成する

MySQL のほとんどのユースケースでは、インスタンスのデフォルトのネットワーク帯域幅の制限内に収まります。この方法でニーズを満たせる場合は、Tier_1 ネットワーキングにアップグレードする必要はありません。

ブロック ストレージを構成する

Google Cloud Hyperdisk は、最近の Compute Engine VM ファミリーで使用可能な耐久性のある唯一のブロック ストレージです。Hyperdisk Balanced は、ほとんどの MySQL ワークロードに最適です。Hyperdisk の詳細については、Hyperdisk のドキュメントをご覧ください。

Google Cloud Hyperdisk

Hyperdisk Balanced には次の機能があります。

  • 低コストでソリッド ステート ドライブ（SSD）のレイテンシを実現
  • 必要なアプリケーション向けのハイ パフォーマンス構成
  • 99.999% を超える耐久性により、ハードウェア障害やサイレント データ破損という業界全体のリスクから保護
  • Google マネージドまたは顧客管理の暗号鍵を使用した、すべての Hyperdisk 保存データの暗号化

パフォーマンス レベルを選択する

Hyperdisk Balanced では、ディスクのストレージ サイズとは別にパフォーマンス レベルを選択できます。これにより、データベースのパフォーマンスを最適化しながら、ワークロードに必要な入出力（I/O）リソースの料金のみを支払うことができます。MySQL データベースのバッファプールがワーキング セットよりも大きい場合、安定状態のオペレーション中に、ディスクにアクセスせずにバッファプールからほぼすべての読み取り、クエリを処理できます。

Hyperdisk ボリュームのパフォーマンス レベルを選択するには、MySQL 書き込みワークロードを検討します。特に、次の点に注意してください。

  • InnoDB REDO ログへのアクセス
  • InnoDB データファイルとインデックスのその後の更新

安定状態のオペレーション以外にも、データベースのメンテナンス イベントによってディスク パフォーマンスが急上昇することがあります。この発生頻度はデータベースの書き込みワークロードに比例する傾向があるため、クラッシュ後の復元で REDO ログを使用する場合や、前回のバックアップ以降のすべてのデータベース変更を読み取って自身をコピーするバックアップ システムを使用する場合などに発生しやすくなります。

ディスクのサイズを設定する

ディスク パフォーマンスの上限値を設定する一般的な戦略は次の 3 つです。

  1. デフォルトの構成を使用する。各ディスクには、少なくとも 3,000 入出力/秒（IOPS）と 140 MiBps のスループットが設定されています。これは、基本的な MySQL ワークロードとオペレーティング システム（OS）のブート ボリュームに十分です。この上限を超えるユースケースの場合は、ワークロードを停止せずに、オンデマンドでプロビジョニングされた I/O パフォーマンスを変更できます。
  2. 既存の使用量を測定する。データベースが別の環境ですでに実行されている場合は、ディスクの IOPS とスループットを 1 分以下の粒度で記録します。1～2 週間分のデータが収集されたら、そのデータセットから高いパーセンタイル値を選択し、有機的成長や予期しない使用量を考慮して、小さなバッファを追加します。
  3. ニーズを見積もり、後で変更する。既存のデータソースがない場合は、最初にパフォーマンスのニーズを見積もり、デプロイ後にさらに調整する必要があります。ワークロードでパフォーマンスのボトルネックが発生しないように、最初は必要と思われる値よりも高い値をプロビジョニングし、最終的にワークロードに合わせてプロビジョニングされたパフォーマンスを削減することをおすすめします。

ディスクのパフォーマンスを向上させる

各 Hyperdisk Balanced ディスクのパフォーマンスは、最大 160,000 IOPS と 2,400 Mbps のスループットまで増やすことができます。VM のサイズは Hyperdisk の最大パフォーマンス上限を決定する際に役立ちます。そのため、Hyperdisk のパフォーマンスを非常に高くしたい場合は、VM のコア数の増加が必要になることがあります。最も負荷の高いワークロードで、単一の Hyperdisk Balanced ディスクよりも高いディスク パフォーマンスが必要な場合は、次のいずれかの方法で複数の Hyperdisk Balanced ディスクをストライピングできます。

  • Hyperdisk Extreme にアップグレードする
  • mdadm などの別のソフトウェア冗長アレイ（RAID）メカニズムを使用する

MySQL データベースをスケーリングする際に、ダウンタイムなしでディスクの容量とパフォーマンスを動的に増やすことができます。これにより、RAM に収まらずディスクにスピルする大規模で複雑な結合を行うオンライン分析処理（OLAP）スタイルのワークロードのパフォーマンスが向上します。まれに、ストレージ レイテンシが非常に低く、データ損失を許容できる MySQL ワークロードでは、ローカル SSD に完全なデータセットを保存できます。次のハイブリッド ソリューションを使用して、読み取りレイテンシを改善し、耐久性の低下を抑えることもできます。

  • Hyperdisk とローカル SSD の間でデータセットをミラーリングします。
  • ボリューム マネージャーを使用して、基盤となる Hyperdisk に保存されたデータのキャッシュとしてローカル SSD を構成します。

Hyperdisk の追加機能を利用する

Hyperdisk には、オンプレミスの高可用性と障害復旧のワークフローを補完または簡素化できる次の機能もあります。

Compute Engine 用 MySQL でこれらの機能を構成する方法については、このページの次の高可用性セクションをご覧ください。

ローカル SSD

一部の Compute Engine マシン ファミリーでは、Hyperdisk の代わりにローカル SSD を使用できます。これらは永続ストレージではありませんが、MySQL ワークロードでは 一時テーブルスペースの保存によく使用されます。

MySQL データベースのスケーリングにローカル SSD を使用する方法については、このページの次のセクションであるディスクの動的なサイズ変更をご覧ください。

Compute Engine のその他の機能

次の Compute Engine 機能を使用して、MySQL デプロイを最適化できます。

Cloud Monitoring

VM のパフォーマンスとインフラストラクチャ サービスの使用状況をモニタリングするには、Google Cloud コンソールを使用します。[VM インスタンス] ページの [オブザーバビリティ] タブで、CPU とメモリの使用率、ネットワーキング帯域幅、インスタンスのプロビジョニングされたパフォーマンスなど、パフォーマンス関連の指標をモニタリングできます。同様に、[ディスク] ページの [オブザーバビリティ] タブでは、ディスク ボリュームのスループットと IOPS をモニタリングできます。

表示するパフォーマンス指標をカスタマイズするには、Cloud Monitoring を使用してクエリを作成します。インフラストラクチャ サービスで表示する特定のパフォーマンス指標を選択できます。MySQL 固有の指標については、Compute Engine に MySQL ワークロード プラグインが用意されています。

オペレーティング システムの構成に関するベスト プラクティス

  • 適切なファイル システムを使用します。Google は、Linux の ext4 ファイル システムと XFS ファイル システムの最適化に重点を置いていますが、ほとんどのファイル システムは MySQL での使用に適しています。
  • 基本オペレーティング システムの構成で Transparent Huge Pages（THP）をオフにします。THP をオフにする手順については、THP のドキュメントをご覧ください。
  • Linux を使用している場合は、ファイル システムのマウント構成に relatime フラグと lazytime フラグを使用します。これにより、ファイルの読み取り、変更、メタデータの変更時に atime、mtime、ctime の値を更新する際のパフォーマンス オーバーヘッドが軽減されます。

MySQL の構成に関するベスト プラクティス

MySQL には次の構成設定を使用することをおすすめします。

  • 最新バージョンの MySQL を使用する。Google は、MySQL バージョン 8.0 以降のバージョンの最適化に重点を置いています。

  • バッファプールのサイズを大きくする。MySQL は、バッファプールを使用して、データを RAM 内のキャッシュに保存します。これにより、ディスク アクセスが減り、読み取りパフォーマンスが向上します。デフォルトでは、MySQL のバッファプール サイズは 128 MiB です。これでは、実際のほとんどのユースケースで小さすぎます。innodb_buffer_pool_size のサイズは、アプリケーションがデータベースでアクセスするワーキング セットのサイズよりも大きくすることをおすすめします。通常、これには次の手順が含まれます。

    1. MySQL インスタンスの実行中のコピーで、ワーキング セットのサイズを測定または見積もります。
    2. そのワーキング セットに十分な RAM を備えた仮想マシン（VM）のサイズとシェイプを選択します。
    3. 使用可能な RAM の大部分を占めるように、VM のバッファプールのサイズを構成します。

  • 二重書き込みバッファをオンにする。MySQL には、torn writes からの保護に役立つ二重か込みもバッファがあります。これは、ディスク上の複数のブロックをカバーする書き込みの途中でハードウェア障害または停電が発生した場合に、部分的にしかコミットされない障害モードです。この保護を利用するには、innodb_doublewrite をオンにします。

  • innodb_flush_log_at_trx_commit の値は 1 に設定します。これにより、書き込みトランザクションがコミットされるときに、ディスク上で永続化されます。

  • パフォーマンスのオーバーヘッドを削減するには、innodb_flush_method の値を指定します。MySQL バージョン 8.0.14 以降では、innodb_flush_method の値を O_DIRECT_NO_FSYNC に設定します。これは最適ですが、これらのバージョンにのみ存在します。8.0.14 より前の MySQL バージョンの場合は、innodb_flush_method の値を O_DIRECT に設定します。

  • 高可用性レプリケーション シナリオでは、プライマリ データベース インスタンスの sync_binlog の値を 1 に設定します。MySQL はバイナリログを使用して、プライマリ データベースからセカンダリ データベースに変更を伝達します。これにより、バイナリログはトランザクション コミット時にコミットされ、データベース間のレプリケーション遅延と復旧ポイント目標（RPO）を可能な限り最小限に抑えることができます。

  • C シリーズのマシン ファミリーで MySQL を使用する場合は、innodb_numa_interleave をオンにします。これにより、MySQL のバッファプールで非均一メモリアクセス（NUMA）ポリシーを利用できます。

二重書き込みバッファをオフにするタイミング

欠落した書き込みから保護する MySQL の二重書き込みバッファには、MySQL 書き込みトランザクションで最大 25% のパフォーマンス オーバーヘッドがあり、トランザクション レイテンシに影響する可能性があります。Google Cloud Hyperdisk には、書き込みの破損保護機能もあります。そのため、MySQL を使用して Hyperdisk で実行されている ext4 ファイル システムに直接書き込む場合は、doublewrite バッファを安全にオフにできます。

ただし、Hyperdisk の書き込み中断保護を有効にするには、データベースとディスクの間のファイル システムや他の中間ソフトウェア レイヤを構成して、ディスクレイヤより上の書き込み中断が発生しないようにする必要があります。次のリストは、Hyperdisk レイヤより上の書き込みの破損を引き起こす可能性のある構成の例を示しています。

  • Google Kubernetes Engine やセルフホスト Kubernetes などのコンテナ内で MySQL インスタンスを実行する。
  • MySQL ファイルを XFS ファイル システムに保存する。このファイル システムは、ほとんどの Linux カーネル構成で十分な大きさのブロックサイズをサポートしていません。
  • ディスク ストライピングを引き起こす独立ディスクの冗長アレイ（RAID）構成（Linux の場合は mdadm、Windows の場合は Storage Spaces と Storage Spaces Direct など）に MySQL ファイルを保存する。
  • Linux の Logical Volume Manager（LVM）や Windows の Storage Spaces、Storage Spaces Direct などのボリューム マネージャーの上に MySQL ファイルを保存する。

  • ローカル ソリッド ステート ドライブ（SSD）をキャッシュとして構成し、Hyperdisk に MySQL ファイルを保存する（Linux の場合は lvmcache、dm-cache、bcache、Windows の場合は Storage Spaces などを使用）。

  • ネストされた仮想化を使用して、VM 内で MySQL インスタンスを実行する。

前述の構成は、書き込みの破損が発生しないように設定できますが、特定の構成が安全であることを検証するのが難しいため、これらの構成を使用する際に二重書き込みバッファをオフにすることはおすすめしません。

（省略可）二重書き込みバッファをオフにする

二重書き込みバッファをオフにするには、次の操作を行います。

  1. ext4 ファイル システムでは、bigalloc 機能を有効にして、ファイル システムのクラスタサイズを 16 KiB、または 16 KiB の 2 の累乗倍数に構成する必要があります。これにより、MySQL の書き込みが Hyperdisk に発行される前に、ファイル システムによって個別の IO に分割されることはありません。上限を引き上げなかった場合や、16 KiB より小さい値を使用した場合、書き込みの破損を防ぐことはできません。クラスタサイズが 16 KiB の例を次に示します。これは、ファイル システムの作成時に構成されます。

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. innodb_doublewrite を無効にして、innodb_flush_method を O_DIRECT または O_DIRECT_NO_FSYNC に設定します（上記の MySQL のバージョンによって異なります）。

高可用性（HA）とバックアップ ソリューションを構成する

すべての重要な MySQL ワークロードを保護するには、高可用性（HA）ソリューションとバックアップ ソリューションを構成することを強くおすすめします。HA とバックアップの両方で、次の要素が最も重要です。

一般的に、HA ソリューションは RTO と RPO をほぼゼロにすることを目標としていますが、これは、インフラストラクチャの障害に対する保護のみを目的としています。バックアップ ソリューションは、RTO と RPO の時間枠を長くすることを目標としていますが、次のような障害シナリオを幅広くカバーします。

  • データの誤削除
  • ランサムウェア攻撃
  • 自然災害

高可用性（HA）を構成する

HA 機能は、ストレージとコンピューティングの冗長性を使用して、ホストの障害や停止が発生した場合に MySQL データベースのダウンタイムを短縮します。これにより、インスタンスまたはゾーンが使用できない場合でも、クライアント アプリケーションがデータにアクセスできるようになります。

MySQL では、次のモードでレプリケーションが可能です。

  • 非同期モード。非同期モードの場合、プライマリは書き込みトランザクションがローカルでコミットされるとすぐに確認応答を送信します。そのため、プライマリで停止が発生した場合、フェイルオーバー中に最近書き込まれた少量のデータが失われる可能性があります。RPO は 0 に近いですが、実際には 0 ではありません。
  • 準同期モード。準同期モードでは、構成可能な数のレプリカがトランザクションの受信を確認するまで、プライマリはトランザクションの確認を待機します。RPO が事実上ゼロになるため、計画外のフェイルオーバー中にデータ損失が発生する可能性が大幅に減少します。

どちらのモードでも、RTO はヘルスチェックが次の処理をどれだけ迅速に行うかによって決まります。

  1. 失敗したインスタンスを特定する。
  2. フェイルオーバーをトリガーする。
  3. ドメイン ネーム システム（DNS）またはデータベース サーバーを識別する別の方法を使用して、フェイルオーバー インスタンスがプライマリになったことをクライアントに通知する。

どのレプリケーション モードでも、レプリケート先のフェイルオーバー インスタンスが必要です。このインスタンスは、次のいずれかの場所で確認できます。

  • プライマリ インスタンスが配置されているゾーンと同じゾーン
  • プライマリが配置されているリージョン内の別のゾーン
  • プライマリとは異なるリージョン

ゾーンの停止時でも高可用性を維持するには、次の構成をおすすめします。

  • プライマリ インスタンスとフェイルオーバー インスタンスが同じリージョン内にあるかどうかに関係なく、異なるゾーンに配置します。
  • 非同期レプリケーションを使用します。準同期レプリケーションを使用している場合、プライマリ インスタンスとフェイルオーバー インスタンスを別々のゾーンに配置すると、書き込みトランザクションの commit のレイテンシが高くなる可能性があります。
  • RPO をゼロにする必要がある場合は、Hyperdisk Balanced High Availability を使用します。これにより、同じリージョン内の 2 つのゾーン間でディスクを同期的に複製できます。詳細については、Hyperdisk High Availability を使用して HA サービスを提供する Google のガイドをご覧ください。Hyperdisk Balanced High Availability を構成する場合は、ステートフル マネージド インスタンス グループと統合して、インスタンスの健全性に関する問題を診断し、復元アクションを自動化することをおすすめします。

バックアップとデータ復元プランを構成する

バックアップとデータ復元計画は、偶発的なデータ削除、ランサムウェア攻撃、自然災害などの障害が発生した場合のデータ損失の防止に役立ちます。コンプライアンスと監査の要件を満たすコールド ストレージとしても使用できます。MySQL には、データベース レベルで動作するものとストレージ ボリューム レベルで動作するものなど、多くのバックアップ方法があります。方法を選択する際は、主に RTO と RPO の要件を考慮する必要があります。

データベース レベルでバックアップする

データベース レベルのバックアップでは、MySQL が提供する次のオプションの使用を検討してください。

  • バイナリ ロギングに基づく増分バックアップ。論理データダンプを作成します。次のようなものがあります。
  • バックアップ プロセスを管理するツール（MySQL Enterprise Backup など）。

MySQL のデータベース レベルのバックアップ オプションの詳細については、MySQL のドキュメントのバックアップと復元をご覧ください。

これらのオプションのいずれの場合も、バックアップ データのコピー先となるセカンダリ ストレージ システムが必要です。次のツールをおすすめします。

Hyperdisk を使用してストレージ レベルでスナップショットとクローンを作成する

ストレージ レベルのバックアップでは、Hyperdisk プロダクトを使用して、MySQL データベースの特定時点でのビューのスナップショット作成、クローンの作成、キャプチャを行うことをおすすめします。このアプローチの RPO は、データベースのスナップショットの取得頻度によって異なります。RTO は、使用する特定のソリューションによって異なります。

高速復元が重要で、ゾーン内のバックアップ範囲のみが必要な場合は、Hyperdisk のインスタント スナップショットを使用することをおすすめします。インスタント スナップショットは、特定の時点のデータを増分的にキャプチャし、ディスクのクローン作成によって新しい Hyperdisk ボリュームにデータを迅速に復元できるため、RTO を数分に短縮できます。ディスクの内容が上書き、削除、破損した場合にデータを復元できます。また、ソースディスクと同じゾーンまたはリージョンでローカルに利用できます。詳細については、インスタント スナップショットについてをご覧ください。

元のディスクよりも高い冗長性でデータを保存し、単一の障害がデータのすべてのレプリカに影響しないように別の場所に保存する必要がある障害復旧シナリオでは、Hyperdisk のアーカイブ スナップショットと標準ディスク スナップショットを使用することをおすすめします。アーカイブ ディスク スナップショットと標準ディスク スナップショットは、ディスク内のデータのコピーを特定の時点で作成し、不変形式で冗長性の高い状態で保存します。スナップショット スケジュールなどを使用してディスクのスナップショットを複数作成する場合、Hyperdisk には増分変更のみが保存されます。アーカイブ ディスク スナップショットと標準ディスク スナップショットは、RTO が高くても許容できる場合に適しています。スナップショット ストレージから VM ストレージにデータをコピーすると、復元に時間がかかる可能性があります。詳細については、アーカイブ ディスクと標準ディスクのスナップショットを作成するをご覧ください。

Hyperdisk のインスタント スナップショットとアーカイブ スナップショットおよび標準スナップショットは、単一のディスク内でクラッシュ整合性があります。つまり、スナップショットから復元する場合、MySQL データベースは通常の InnoDB 復元手順を実施して、ログファイルとデータファイルを整合性のある状態に戻す必要があります。InnoDB の REDO ログの構成によっては、RTO が長くなる可能性があります。次のパターンを使用すると、一貫性のあるデータベース スナップショットの作成がさらに複雑になる可能性があります。

  • MySQL データベース ファイルが複数のボリュームに分散している。
  • mdadm などの Linux ソフトウェア RAID ユーティリティを使用している。
  • MySQL の構成済みストレージ ロケーションを、異なるディスク上のファイル システムに分離している。

スナップショットの復元後に復元を必要としないスナップショットを作成するには、次の操作を行います。

  1. MySQL データベースへの書き込みアクセスを一時的にロックします。
  2. LOCK INSTANCE FOR BACKUP コマンドと FLUSH TABLES WITH READ LOCK コマンドを使用して、進行中のすべてのバッファをディスクにフラッシュします。
  3. スナップショット オペレーションを開始します。

  4. マルチディスク シナリオでは、MySQL レベルでフラッシュした後、サーバーで sync コマンドと fsfreeze コマンドを実行して、進行中のすべての書き込みをディスクにフラッシュし、ファイル システム レベルで新しい受信書き込みを一時停止します。

データベースの初期スナップショットをキャプチャしたら、Hyperdisk は特定時点のビューを迅速にキャプチャし、後続のストレージ コピー手順を非同期で処理できるため、ディスクのロックを継続する必要はありません。スナップショットの整合性を確保するためにこれらの手順が必要で、プライマリ データベースへの書き込みの影響を排除したい場合は、プライマリ データベースではなくデータベース レプリカに対してバックアップを実行することもできます。

次のステップ