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 を使用し、最新世代のインテル、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）のパフォーマンスを重視する場合は、ブロック ストレージが主な考慮事項となります。詳細については、このページのブロック ストレージを構成するをご覧ください。

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

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

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

ほとんどの 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 リドログへのアクセス
  • 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 へのアップグレード
  • 別のソフトウェア冗長独立ディスク（RAID）メカニズム（mdadm など）を使用する。

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

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

Hyperdisk のその他の機能を使用する

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

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

ローカル SSD

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

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

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 には、破れた書き込みから保護するダブルライト バッファがあります。破れた書き込みとは、書き込みの途中でハードウェア障害または停電が発生した場合、ディスク上の複数のブロックにわたる書き込みが部分的に commit される障害モードです。この保護を利用するには、innodb_doublewrite をオンにします。

  • innodb_flush_log_at_trx_commit の値を 1 に設定します。これにより、書き込みトランザクションが commit されたときにディスク上で永続的になります。

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

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

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

ダブルライト バッファをオフにするタイミング

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

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

  • Google Kubernetes Engine やセルフホスト Kubernetes などのコンテナ内で MySQL インスタンスを実行する。
  • MySQL ファイルを XFS ファイル システムに保存している。ほとんどの Linux カーネル構成では、十分な大きさのブロックサイズがサポートされていません。
  • ディスク ストライプ化を発生させる独立したディスクの冗長アレイ（RAID）構成に MySQL ファイルを保存する（Linux の場合は mdadm、Windows の場合は Storage Spaces や Storage Spaces Direct など）。
  • Linux の 論理ボリューム マネージャー（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 に送信される前に、ファイル システムによって個別の I/O に分割されなくなります。上限を引き上げなかった場合や、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 では、次のモードでレプリケーションが可能です。

  • 非同期モード。非同期モードでは、プライマリは書き込みトランザクションがローカルで commit されるとすぐに確認応答を送信します。そのため、プライマリで停止が発生した場合、RPO はゼロに近い（ただしゼロではない）ため、フェイルオーバー中に最近書き込まれた少量のデータが失われる可能性があります。
  • 半同期モード。準同期モードでは、構成可能な数のレプリカがトランザクションの受信を確認するまで、プライマリはトランザクションの確認を待機します。これにより、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 バックアップなど）。

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 は特定の時点のビューを迅速にキャプチャし、その後のストレージ コピー ステップを非同期で処理できるためです。スナップショットの整合性のためにこれらの手順が必要で、プライマリ データベースへの書き込みの影響を排除する場合は、プライマリ データベースではなくデータベース レプリカに対してバックアップを実行することもできます。

次のステップ