GCP DMS を使用して 150 個のクラウド SQL インスタンスを移行した方法

当社の Cloud SQL インスタンスは、その中心的な部分です。 Glean インデックス構築アーキテクチャ。とりわけ、クロールされたすべてのデータのリポジトリとして機能し、最終的には提供されたインデックスに送られます。また、次のような他の情報も保存します。 答える Glean ユーザーによって作成されました。Glean を始めたとき、私たちはこれらすべてをGoogleのビッグテーブルに保存していましたが、後でコスト上の理由からCloud SQLに移行しました。これまで、当社の Cloud SQL インスタンスはすべて MySQL5 インスタンスでした。GCP が MySQL8 のサポートを開始した直後に、これらのインスタンスを MySQL8 に移行することを決定しました。

モチベーション‍

最新かつ最高のバージョンを使用することに加えて、移行に伴う主な動機は、その一環として導入された JSON の改善でした。 MySQL 8。MySQL8より前は、JSON列を操作する一部のAlter Tableコマンドに長い時間がかかったため、一部のアップグレードが完了するまでに48時間近くかかることがありました。MySQL8を使用すると、JSONをその場で更新できる可能性があるため、このような操作を大幅にスピードアップできると考えていました。

主な課題

1. これはメジャーバージョンアップグレードだったので、完全に新しい MySQL8 インスタンスを作成し、古いインスタンスからデータをコピーする必要がありました。コピーする必要があったこのデータのサイズは、TB 単位のデプロイメントの一部ではかなり大きかったです。
2. データのコピーが行われている間、ソース DB を通常の操作に使用できるようにする必要がありました。
3. サービスがDBにどのように接続されているかにもよりますが、最終的に古いDBから新しいDBに切り替えたときに、一部のサービスを再起動する必要がありますが、一部のサービスは再デプロイする必要があります。また、GCP 接続設定の変更を検出してメモリ内の SQL 接続プールを更新するサービスもいくつか実装しました。これにより、再起動や再デプロイが不要になりました。
4. 切り替えは一部のサービスの再展開を意味する可能性があるため、これは誰かの監督下で行われる必要がありました。また、これは、システムに対する顧客の負荷が低い場合にのみ発生する可能性があったことを意味していました。

GCP DMS を使用する

上記の制約を考慮して、GCP DMS を使用してデータベースを MySQL5 から MySQL8 に移行することにしました。DMS は、SQL ワークロードを他のインフラストラクチャから Google マネージドクラウド SQL インスタンスに移行する場合に Google が推奨するサービスです。使用することにしました 連続 初期ダンプフェーズを使用し、CDCフェーズでプライマリセカンダリレプリケーションを使用するタイプの移行ジョブ。レプリケーションラグを監視し、レプリケーションラグが小さくなったら、古いインスタンスから新しいインスタンスに切り替える準備ができました。この条件は一日中いつでも満たされる可能性がありますが、カスタマーサービスの中断を最小限に抑えるため、インスタンスを切り替えたのは夜間と週末のみでした。

非同期操作フレームワーク

‍これまで、私たちのアップグレードは以下によって実行されていました プッシュマスター 誰がアップグレードを継続的に監視しているのか。ほとんど2時間走ります。ただし、データサイズが大きいため (上記のポイント 1)、SQL のアップグレードは何日もかかると予想されていました。また、それぞれ2つのクラウドSQLインスタンスを持つ75近くのプロジェクトをアップグレードする必要があったため、手動でのアップグレードは面倒でした。いわゆるものを実装することにしました 非同期アップグレードフレームワーク この問題を解決するために。

大まかに言うと、これはステートマシンです。アップグレードの現在の状態は、状態ファイルと呼ばれるファイルの GCS バケットに保存されます。定期的にチェックが入り、状態ファイルが読み込まれ、移行の現在の状態を調べる GCP クエリが送信されます。次に、これら 2 つの入力に応じて、ステートマシンは状態を更新し、何らかのアクションを実行します。その一例として、移行ジョブの現在の状態が実行中で、レプリケーションラグを調べたところ、かなり大きいために同じ状態にとどまっていることが挙げられます。ただし、レプリケーションラグが低く、システムの使用率が低いことがわかった場合（上記のポイント4）、新しいインスタンスにパッチを適用して切り替え、再起動と再デプロイをトリガーして状態遷移を行うことにしました。

このフレームワークで実行されるすべての操作は、問題が断続的に発生する場合に備えて等価である必要があります。そのため、次の段階までシステムを一貫した状態にしておく必要があります。

MySQL8 を使用した場合と MySQL5 を使用した場合のメリット

Glean ワークロードにおけるMySQL8とMySQL5のパフォーマンスの詳細な比較は別の投稿のトピックになるかもしれませんが、初期の兆候には次のものがあります。

• 同じワークロードで CPU が大幅に向上しました。たとえば、あるケースでは、CPUは約30％でしたが、当初は50％前後で推移していました。
• ディスク読み取り I/O が低くなります。
• メモリ使用率は似ているようです。MySQL はメモリを使用可能なメモリの約 85% に抑えようとしていると思います。
• また、似たようなクエリのキャッシュも大幅に改善されました。

いくつかの学習

‍プロジェクトの過程で、私たちは多くのことを学びました。

• ソース DB の負荷が高い場合、レプリケーションの遅延を迅速に減らすことは困難です。当初、レプリカが追いついてきたとき、ソース DB をフルスロットルで実行させることにしました。並列レプリケーションとトランザクションコミットのセマンティクスのパラメーターを調整することで、遅延を減らすことができると想定していました。しかし、それが私たちのケースではうまくいかないことにすぐに気付きました。ソース DB のアクティビティを一時停止する必要がありました。
• 初期ダンプ時間が長い:データがソース DB のいくつかのテーブルに集中している場合、初期ダンプは非常に長くなります。あるプロジェクトで、約 90% のデータが1つのテーブルに含まれるケースがありました。最初の試みでは、最初のダンプに7日以上かかりました。ソースでのレプリケーションログの最大保存期間は 7 日間であるため、ジョブが正しい更新を取得することは決してありません。幸いなことに、DumpFlags を使用してこのデータの一部を無視し、新しいインスタンスへの切り替えが行われたら再クロールすることができました。
• 顧客ごとに個別のGCPプロジェクトがある現在のモデルでのスケーリングは、将来の移行では難しい場合があります。より多くの顧客向けに単一プロジェクトを行うマルチテナントアーキテクチャに移行する必要があります。‍

‍もし 建物 または を使用します クラス最高の検索製品がおもしろそうですね。ぜひお話しください。