InnoDBからMyRocksへのデータベースの移行

ゾージ・ラ、インド

こんにちは、Habr！ 私の名前はオレグエフィモフです。私はBadooチーム「プラットフォーム」で働いており、写真、サービスインターフェースなどを保存するタスクに従事しています。

サーバーテクノロジーに関して、Badooはかなり保守的な会社だとよく耳にします。 これは部分的には真実ですが、実際には、多くの若いプログラミング言語、新しいツール、テクノロジーを使用しています。 その1つがRocksDBで、これに基づいてFacebookがMySQLストレージエンジンであるMyRocksを作成しました。 Facebookがそのデータベースの1つをInnoDBからMyRocksにどのように移行したかについての投稿、私はあなたのために翻訳したかった。

昨年、新しいMySQLデータベースエンジンであるMyRocks を導入しました。これは、圧縮されたInnoDBよりも効率的にドライブを記録および使用できるように設計されています。 メインデータベース（UDB）の1つを圧縮されたInnoDBからMyRocksに移行し、ストレージのサイズと使用するサーバーの数を半分にすることにしました。 Facebookソーシャルグラフデータを管理するUDBデータベースの移行は、慎重に計画および実装されました。 先月作業を完了し、ストレージを半分に減らしました。 この投稿では、移行の準備と実装、および学んだ教訓について説明します。

UDBはストレージによって制限されていました

数年前、私たちはいくつかのパフォーマンスの問題を解決するために、UDBが実行するハードウェアをFlashcacheから純粋なFlashに置き換えました。 InnoDBを含むMySQLバンドルは迅速かつ確実に機能しましたが、同じ負荷とデータ量を処理するために使用するサーバーの数を減らしたいと考えました。 純粋なフラッシュストレージを使用する場合、UDBの範囲は制限されていました。 また、InnoDBで圧縮を使用しましたが、プロセッサリソースとランダムI / Oの帯域幅は過剰でしたが、InnoDBに使用するディスクスペースを少なくすることはほとんどできませんでした。

InnoDBは空きディスク容量によって制限され、CPU / IOリソースはアイドル状態でした。 これは、フラッシュストレージを使用する場合の一般的な状況です。

これは、MyRocks（MySQL用のRocksDBストレージエンジン）を作成する動機の1つでした。 InnoDBにはいくつかの機能が実装されており、データベースのサイズがはるかに多くのRAMでした：

• クラスター化インデックス。
• トランザクション（原子性、ラインロック、MVCC、反復可能読み取り/読み取りコミット、binlogとRocksDB間の2PC）;
• 破損に強いスレーブとマスター。
• SingleDelete （セカンダリインデックスの効果的な削除）;
• データの高速ロード、インデックスの迅速な作成、テーブルの迅速な削除。

初期の実験では、MyRocksは圧縮されたInnoDBと比較して、CPU消費量とI / O操作の数を大幅に増加させることなく、使用するスペースが半分であることが示されました。 そのため、UDBをInnoDBからMyRocksに完全に移行することにしました。

MyRocksにMyRocksのダブルロード。 プロセッサリソースとI / O操作の予約はまだあります。

InnoDBからMyRocksへの移行を簡素化する

ユーザーがデータベースに直接アクセスするサービスの場合、このような移行は困難な作業になる可能性があります。 一般に、既存のOLTPデータベースの場合、これは、サービスを停止することなく、待ち時間を増やしてスループットを低下させることなく、誤ったデータを返さず、ワークロードに影響を与えることなく実行できます。

MyRocksには、他のデータベースに比べて独自の利点があります。MySQLストレージエンジンを備えているため、InnoDBからの移行が大幅に促進されます。 特に：

• MySQLクライアントのプロトコルとスキーマの定義は同じであるため、アプリケーションに変更を加える必要はありませんでした（実際、ギャップロックなどのわずかな違いがありますが、それらを考慮するのは比較的簡単でした）。
• MySQLの管理ツールはInnoDBとMyRocksの両方をサポートしています。
• MyRocksはInnoDBから複製できます。MyRocksのインスタンスを追加して、読み取り専用スレーブの1つとして起動できます。
• InnoDBはMyRocksから複製することもできます。InnoDBを放棄することなくMyRocksをマスターにデプロイできます。これにより、問題が発生したときにマスターを切り替えることでMyRocksからInnoDBに切り替えることができます。
• グローバルトランザクション識別子（GTID）を含むバイナリログを使用すると、長いレプリケーション停止（1秒未満）を行うことなく、InnoDBインスタンスとMyRocksインスタンス間のデータの整合性を確認できます。

データの整合性チェック

MyRocks / RocksDBは新しいテクノロジーであるため、データベースに新しいバグが出現するのを防ぐために、包括的な一貫性チェックに頼らなければなりませんでした。 検証は、移行中と本番環境での起動後の両方で常に実行されます。

主キーと副キーの整合性の検証。 各テーブルは、主キー列と副キー列の行数とチェックサムを比較します。 たとえば、テーブルT1には列（id、value1、value2）とセカンダリインデックス（value1）があります。 次に、value1に対してプライマリキーとセカンダリキーがスキャンされ、行数とチェックサムが比較されます。 キーの1つが破損している場合、チェックサムは収束しません。

2つのインスタンスの一貫性を確認します。 1つのレプリカセット（マスターとスレーブのペア）で、2つの異なるインスタンス（MyRocksとInnoDB）が行数と主キーのチェックサムによって比較されます。 GTIDのおかげで、両方のインスタンスで同じGTIDの一貫したスナップショットでトランザクションを開始できます。 後続のSELECTステートメント（行カウントとチェックサムを返す）は、両方のインスタンスで一貫している必要があります。

2つのコピーに対する要求の正確性のシャドウチェック。 MySQLには、実行された要求を登録できる監査プラグインと呼ばれる機能があります。 これらのクエリを複数のインスタンスで繰り返しシャドーし、結果を比較するツールを作成しました。 これにより、InnoDBとMyRocksのクエリで同じ結果が得られるようになりました。

移行段階

移行は以下に説明する方法で行われ、InnoDBとMyRocksの間でレプリケーションを構成できるため、簡単になりました。

1） 最初のスレーブMyRocksを展開しました。 世界中の地域のレプリカセットごとに、1つのマスターと4つのスレーブがありました。 各レプリカセットで、同じリージョンのInnoDBからのダンプ（mysqldump）を使用して最初のMyRocksインスタンスを作成しました。 アップロードおよびダウンロード中に、元のInnoDBスレーブインスタンスのレプリケーションを停止して、移行を高速化および簡素化しました。 また、アップロードおよびダウンロード中に、すべての読み取り要求がInnoDBの他の利用可能なスレーブインスタンスにリダイレクトされました。

MyRocksはデータのロードとセカンダリインデックスの作成に最適化されているため、アップロードとダウンロードにそれほど時間はかかりませんでした（エンジンはInnoDBから1時間あたり数百ギガバイトをコピーできます）。 レプリケーションが追いつき、データの一貫性がチェックされた後、同じリージョンのInnoDBを削除しました。

2） 2番目のスレーブMyRocksをデプロイしました 。 MyRocksの単一のインスタンスを操作しないようにしたかったのは、その損失が再アップロードとダウンロードの必要性につながったからです。 2つのインスタンスの1つが失敗した後、2つのインスタンスを操作する場合、MyRocksのバイナリオンラインコピー（myrocks_hotbackup）を使用して回復できます。これは、アップロードとダウンロードに比べてはるかに簡単です。 MyRocksを展開する前に、レプリカセットごとに5つのInnoDBインスタンスがありました。

各地域で、InnoDBの2つのインスタンスを削除した後、MyRocksの2つのインスタンスを追加しました。 結果は、InnoDBの3つのインスタンスと、レプリカの各セットのMyRocksの2つです。 MyRocksはデータをより高速にロードするため、InnoDBにコピーするよりもアップロードがはるかに簡単でした。 これにより、移行中であっても、物理サーバーの数を増やすことなく移行できました。

3） スレーブMyRocksをマスターにしました。 マスターインスタンスは書き込み要求と読み取り要求の両方を処理できるため、マスターの展開はスレーブよりもはるかに困難でした。 たとえば、マスターでは書き込み操作が同じ行で同時に実行されるため、行ロックの正しい処理を実装する必要があります。 一貫性の不十分な実装は、多くのエラーにつながる可能性があります。

4） すべてのリージョンで、彼らはMyRocksをコピーし、InnoDBのすべてのインスタンスを削除しました 。 最後のステップは、MyRocksをコピーしてInnoDBを削除することでした。 これで、レプリカセットがInnoDBからMyRocksに完全に移行されました。

実稼働環境では、最初にすべてのUDBレプリカセットに対して最初の2つのステップを実行しました。 その後、ほとんどのセットで、3番目の段階が完了し、最後に最後の段階が完了しました。 最も難しいのはマスターをデプロイすることだったので、先に進む前に多くのテストを行いました。 クエリ複製ツールを使用して、マスターのトラフィックをチェックし、マスターを運用環境に展開する前に一貫性のバグを修正できるようにしました。

その他の技術的ポイント

InnoDBでは直接I / Oを使用しましたが、MyRocks / RocksDBではサポートが制限されているため、バッファーI / Oを使用しました。 古いLinuxカーネルでは、バッファリングされた操作をアクティブに使用しているときにディスクからのスワッピングが開始され、仮想メモリの割り当てが難しくなるという既知の問題があります。 Linuxカーネルチームは、Linux 4.6の仮想メモリの割り当てに関する問題を修正し、移行前にカーネルをこのバージョンにアップグレードしました。

また、各マシンでMySQLのいくつかのインスタンスを実行しました。 各インスタンスのサイズは5TBのフラッシュストレージの容量よりもはるかに小さく、データベースの操作を改善するのに役立ちました。バックアップ、復元、レプリカの作成、レプリケーションラグの防止です。 移行中、InnoDBインスタンスの削除に続いて、MyRocksインスタンスを徐々に作成しました。 フラッシュストレージでは、アクティブなファイルの削除により、最大数十秒の長いTRIM遅延が発生します。 この制限を知っており、ファイルを少しずつゆっくり削除する簡単なツールを作成しました。 「rm」コマンドを使用して100ギガバイトのInnoDBファイルを削除する代わりに、彼は大きなファイルをそれぞれ約64 MBのチャンクに分割し、各ファイルを短時間で削除しました。 削除速度を約128 MB /秒に低下させました。

学んだ教訓

業務にとって効率は重要であり、本番環境で問題を引き起こすことなく迅速に移行できたことを嬉しく思いました。 しかし、その過程で、いくつかの重要な教訓を学びました。

• 機器を選択する際の主な基準の1つは、予測される移行期間です。 たとえば、移行が終了するまで新しい機器を購入し続ける必要があるため、移行あたり1年ではなく5年とすると、ストレージの節約量が減少する可能性があります。 テストの自動化と簡素化により、プロセスが容易になります。例：

1. シャドウ読み取り/書き込みトラフィックを送信し、運用環境での回帰を監視します（特にエラーとフリーズの数、遅延のレベル）。
2. InnoDBとMyRocksのデータの一貫性を確認してください。
3. MyRocksのスレーブおよびマスターインスタンスを意図的にクラッシュさせ、回復する能力をテストします。

• ターゲットサービスの使用方法を理解する必要があります。 MyRocksに最初に追加する機能を決定することが重要でした。 移行を容易にするために、ギャップロックを使用したリクエストの定義、バルクロード、Read Committed分離レベルなど、いくつかの重要な機能を追加しました。 適切な優先順位付けにより、移行が簡素化および高速化されます。
• 小さく始めます。 理想的には、最初に、必要に応じてロールバックできる非常に小さな読み取り専用インスタンスに新しいソフトウェアを展開する必要があります。 サイトの円滑な運用を担当するエンジニアは、構成ファイルを介してサービス全体を切り替えてはならず、すべてが機能することを期待してください。
• MyRocksは、他の製品と連携して新しい機能を作成したり、バグを見つけて修正したりできるオープンソースのツールです。

今後の計画

コアデータベースをInnoDBからMyRocksに移行すると、使用するストレージの量が半分になりました。 MyRocksとRo​​cksDBの改善を継続し、他のタスクのためにインスタンスをより積極的に無料サーバーに統合することを含めます。 また、さまざまなエンジンのサポートにも取り組んでいます。 MyRocksはストレージスペースを節約し、記録されたデータの成長を遅らせるように最適化されていますが、InnoDBは読み取り用に最適化されており、ギャップロック、外部キー、フルテキスト、空間インデックスなどの高度に特殊化された機能を備えています。

MyRocksの現在の開発は、こうしたものの導入を意味するものではありませんが、いくつかのエンジンに信頼性の高いサポートを提供する予定です。 InnoDBとMyRocksを同時に使用すると、InnoDBを小さくてアクティブに読み取り可能なページに使用し、MyRocksを他のすべてに使用できます（この機能を実装する要求をよく耳にします）。 最後に、今後のMySQL 8.0のMyRocksサポートに取り組みます。