Compute Engine で MySQL を構成する

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

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

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

MySQL ワークロードには、最新世代の C マシン ファミリーと N マシン ファミリーを使用することをおすすめします。これらのマシン ファミリーには、ほとんどの MySQL 構成で適切に動作するシェイプが含まれています。これらのマシンシリーズの概要については、次の Trusted Cloud by S3NS ブログ投稿をご覧ください。これらのマシン ファミリーは 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）の高いパフォーマンスを目指す場合は、ブロック ストレージを主な考慮事項とします。詳細については、このページのブロック ストレージを構成するをご覧ください。

1 秒あたりの読み取りクエリ数（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 再実行ログへのアクセス
  • 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 のパフォーマンスとインフラストラクチャ サービスの使用状況をモニタリングするには、Trusted 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 から保護するのに役立つダブルライト バッファがあります。これは、ディスク上の複数のブロックをカバーする書き込みが、書き込みの途中でハードウェア障害や電源障害が発生した場合に、部分的にしか commit されない障害モードです。この保護を利用するには、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 の場合は ストレージ スペースと ストレージ スペース ダイレクトなど）に 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 インスタンスを実行する。

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

（省略可）doublewrite バッファをオフにする

ダブルライト バッファをオフにするには、次の操作を行います。

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

次のステップ