無修正の非同期複製

オレグ・ツァレフ（ zabivator ）

マスターがいて、マスターが突然落ちましたが、システムは動作し続けます。 顧客は2番目のベースに移行します。 データベースのバックアップコピーを作成する必要があります。 メインデータベースでバックアップを作成すると、何らかのパフォーマンスの問題、応答時間の増加が発生する可能性があります。 これは悪いです。 したがって、非同期複製のかなり一般的な例は、スレーブからのバックアップの削除です。 もう1つの例は、マスターデータベースからスレーブへ、メインデータベースから2番目への重いクエリの移行です。 たとえば、レポートの作成。



アプリケーションがデータベースからすべての更新を、できればリアルタイムで受信できることが必要な場合があります。 これは、libslaveと呼ばれるオープンソースライブラリによって行われます。

この記事はOleg Tsarevのレポート（ zabivator ）の転写であり、Olegがこの主題に関する別の記事を公開した1年後-PostgreSQL vs MySQL 。

スライドのリンクをたどって、素晴らしい記事を読んでください。



すべてをまとめると、次のようになります。







マスターとスレーブの束が1つあります。マスターがクラッシュした場合はバックアップ用のseilover、バックアップ用のスレーブ、レポートを作成するためのスレーブ、およびbannerdと呼ばれるものへの変更を中継する複数のスレーブ（これはデーモンの名前であり、libslaveを介して機能します） 。 それらの多くがあるので、そのようなプロキシがあります。



十分に大きなデータベースを持つかなり大きなプロジェクトがありますが、私たちは常に仕事をしていますが、サービスは落ちません。 私たちは広告を配布しますが、かなり深刻な負荷があり、レプリケーションはどこでも使用されます。



データベースの主な特性は、「すべてまたは無」の原則を保証することです。 変更は完全に発生するか、まったく発生しません。 これはどのように行われますか、データベースはどのようにデータの整合性を保証しますか？







データベースにアクセスするサーバー、RAM、ディスク、クライアントがあります。 メモリはページの形式で編成されます。 データを更新するための何らかのリクエストが到着すると、ページは最初にRAMで変更され、次にディスクに到達します。



問題は、最新のハードウェアでは「すべてか無か」という原則が不可能であることです。 これらは世界の物理的な限界です。 RAMを使用する場合でも、トランザクショナルメモリはIntelで最近登場したばかりです。 そして、これと一緒に暮らす方法は明確ではありません...解決策は雑誌です：







私たちは別の場所-ジャーナル-でやりたいことを書きます。 最初にすべてのデータをログに書き込み、ログがディスク上で修正された後、メモリ内のデータ自体を変更します。 その後、おそらくずっと後に、このデータはディスクに保存されます。 つまり 雑誌は多くの問題を解決します。 データの一貫性は機能の1つにすぎません。



このアルゴリズムは、Point In Time RecoveryまたはPITRと呼ばれます。 リンクに関する情報に精通することをお勧めします。







これは非常に有益です。



データベースの開発者に生じる主な質問：

• 雑誌を整理するには？
• 書き方は？
• それを少なく書く方法は？
• より速く動作させる方法は？
• レプリケーションはそれと何の関係がありますか？

レプリケーションを行う直接的な方法は、ログをマスターからスレーブにコピーし、スレーブに適用することです。 ジャーナルは、データの一貫性を保証するために使用されます。 同じメカニズムをスレーブに適用できます。 そして、レプリケーションが行われ、システムにはほとんど何も追加されません。



PostgreSQLはまさにそれを行います。 彼のログは「先行書き込みログ」と呼ばれ、物理的な変更が記録に入ります。 ページの更新。 メモリ内にページがあり、その上にデータがあり、それを使って何かをしました-この違いをログに書き込み、それからスレーブに残します。



MySQLにはいくつのログがありますか？ 正しくしましょう。 当初、MySQLにはログがまったくありませんでした。 MyISAMエンジンはありましたが、雑誌はありません。



写真では、ストレージエンジンと呼ばれるものを見ることができます。







ストレージエンジンは、データをディスクに書き込む方法と、そこからデータを読み取る方法、データを検索する方法などの問題を扱うエンティティです。



その後、レプリケーションを固定しました。 レプリケーションは、左上のボックスの1行-管理サービスとユーティリティです。



レプリケーションにはジャーナルが必要でした。 彼は書き始めました。 バイナリログと呼ばれます。 他の方法で使用することを考えた人はいませんでした。



ほぼ同時期に、MySQLはInnoDBと呼ばれる新しいストレージエンジンを発表しました。 これは広く使用されているものであり、InnoDBには独自の雑誌があります。 InnoDBとBinary Logという2つの雑誌が見つかりました。 この瞬間は戻りのないポイントになり、その後、解決が非常に難しい問題がありました。



バイナリログはポイントインタイムリカバリには使用されず、InnoDB Undo / Redoログはレプリケーションに使用されません。 PostgreSQLには1つのジャーナルがあり、MySQLには2つのジャーナルがありますが、レプリケーションに必要なバイナリログには2つまたは3つの形式（タイプ）があります。



最も簡単に作成できた最初のタイプは、ステートメントベースのバイナリログです。 これは何ですか トランザクションごとに順番に書き込む単なるファイルです。 次のようになります。







トランザクションは、これらの更新が行われたデータベースを示し、トランザクション開始時刻のタイムスタンプが示され、その後トランザクション自体が進みます。



2番目のタイプは、行ベースのレプリケーションと呼ばれます。 これは、リクエスト自体が書き込まれるのではなく、リクエストが変更する行であるジャーナルです。 画像の前と後の2つの部分で構成されています。







写真では、BEFORE画像が上にあり、AFTER画像が下にあります。



BEFOREイメージでは、トランザクションの前にあった行が配置されました。 削除された行は赤でマークされています。







それらは上部のBEFORE画像からのものですが、下部ではなく、AFTER画像では削除されます。



次の図では、追加された行が緑色でマークされています。







BEFOREイメージとAFTERイメージの両方に青いUPDATEがあります。 これらはアップデートです。



このソリューションの問題は、最近まで、行ベースのレプリケーションでは、更新した場合でもすべての列がログに書き込まれることでした。 MySQL 5.6では、これは修復され、これにより簡単になります。



別のタイプのバイナリLog'aがあります-混合ベース。 ステートメントベースまたは行ベースとして機能しますが、広く配布されていません。



これらの雑誌のどれがより良いですか？



最初に、リレーショナルテーブルについて説明しましょう。 多くの場合、リレーショナルテーブルは配列であると考えられています。 これは2次元配列であると考える人もいます。 実際、これははるかに複雑なものです。 このマルチセットは、順序が指定されていない特定の種類のタプルのセットです。 SQLテーブルに順序はありません。 これは重要です。 また、結果として、データベースからSELECT *を作成する（すべてのレコードをスキャンする）と、クエリの結果が変わる可能性があります。行は1つの順序になったり、別の順序になったりします。 これを覚えておく必要があります。



以下は、ステートメントベースのレプリケーションでは正しく機能しないクエリの例です。







テーブルからprimary_keyを削除し、新しいもの-自動増分を追加しました。 マスターとスレーブのステッチの順序は異なります。 そのため、一貫性のないデータが得られました。 これは、ステートメントベースのレプリケーションの機能であり、これを使用して実行できることはあまりありません。



これは公式のMySQLドキュメントからの引用です：







別のテーブルを作成し、そこにデータを転送して、名前を変更する必要があります。 この機能は、最も予期しない場所で「撮影」できます。



次のスライドは、レプリケーションの分類方法に関するレポートで最も重要なものの1つです。







PostgreSQLと同様に、ストレージレベルでの作業は物理レプリケーションと呼ばれます-ページを直接操作します。 また、トランザクションの前後に一連のタプルを保存する行ベースのレプリケーションは論理的です。



また、ステートメントベースのレプリケーションは通常、リクエストレベルで行われます。 彼らはそれをしませんが、それは終わりました...ここから重要な興味深い特性が続きます：行ベースのレプリケーションが私たちのために働くとき、すなわち 論理複製の場合、データがディスクにどのように保存されているか正確にはわかりません。 レプリケーションが機能するためには、メモリ内でいくつかの操作を実行する必要があることがわかりました。



また、物理レプリケーション（PostgreSQL、InnoDB）は主にディスク上にあり、MySQLレプリケーションは主に行ベースとステートメントベースの両方のスレーブ上にあります。 行ベースでは、行を見つけて更新するだけで済みますが、ステートメントベースではすべてがさらに悪くなります。リクエストを完了する必要があります。 たとえば、30分間マスターで要求が実行された場合、30分間スレーブで実行されます。 これは複製ですが、むしろ失敗します。



さらに、PostgreSQLは、データウェアハウスとログの2つの場所でディスクに書き込みます。 MySQLには、ストレージ（テーブルスペース）、ログ（取り消し/やり直しログ）、およびレプリケーションで使用されるバイナリログの3つの場所があります。 1.5倍以上ディスクに書き込む必要があります。 MySQLは優れたアーキテクチャですが、多くの場合問題があります。



多くの人がMySQLレプリカに遅れをとっています。 レプリカブレーキングの理由を見つける方法 診断は困難です。 MySQLには、ログスロークエリと呼ばれる診断ツールがあります。 開いて、最も難しいクエリのトップを見つけて修正できます。 レプリケーションでは、これは機能しません。 統計分析を実行する必要があります-統計を読み取るために-どのテーブルがより頻繁に使用されるようになりました。 これを手動で行うことは非常に困難です。



MySQL 5.6 / 5.7では、SLAVE PERFORMANCE SCHEMAが登場しました。これに基づいて、このような診断をより簡単に実行できます。 通常、パペットでコミットログを開き、レプリケーションが遅れ始めたときに展開した内容を確認します。 これでも役に立たない場合があります。すべての開発者にアクセスして、レプリケーションを中断した場合は何をしたかを尋ねる必要があります。 悲しいことですが、それと一緒に暮らさなければなりません。



非同期レプリケーションには、書き込むマスターと読み取り専用のスレーブがあります。 スレーブはマスターに影響を与えません。 また、PostgreSQLでは影響しません。 MySQLでは、残念ながらそうではありません。 要求を複製するステートメントベースの複製が正しく機能するために、特別なフラグがあります。 InnoDBでは、注意してください、すなわち 私たちのアーキテクチャは、上記のレプリケーションとストレージエンジンを共有します。 しかし、ストレージエンジンは、レプリケーションが機能するために、大まかに言って、テーブルへの挿入を遅くする必要があります。



別の問題は、ウィザードがクエリを並列に実行することです。 同時に、スレーブはそれらを順番に適用できます。 問題が発生します-なぜスレーブはそれらを並行して適用できないのですか？ 実際、これは簡単ではありません。 クエリを並列に実行できるタイミングと、順次実行するタイミングを示すトランザクションシリアル化定理があります。 これは別の複雑なトピックです。たとえば、リンクhttp://plumqqz.livejournal.com/387380.htmlを読んで興味があり必要な場合は整理してください。



PostgreSQLでは、レプリケーションは主にディスクに置かれます。 ディスクは並行しておらず、どういうわけか1つのストリームを気にしません。とにかく、主にディスクに座っています。 CPUをほとんど消費しません。



MySQLでは、レプリケーションはプロセッサ上にあります。 これは美しい画像です。12コアの大規模で強力なサーバーです。 1つのコアが機能すると同時に、レプリケーションでビジーです。 このため、レプリカは窒息しています。 これはとても悲しいです。



リクエストを並行して実行するために、リクエストのグループ化があります。 InnoDBには、トランザクションのグループ化方法、トランザクションのディスクへの書き込み方法を制御する特別なオプションがあります。 問題は、それらをInnoDBレベルでグループ化できることと、より高いレベル（レプリケーションレベル）でグループ化できることです。 2010年、MariaDBのChristian NelsenがGroup Binary Log Commitと呼ばれる機能を実装しました。これについては後で説明します。 Storage Engineとレプリケーションの2つのレベルでジャーナルを繰り返し（これはかなり複雑なデータ構造です）、機能をあるレベルから別のレベルにドラッグする必要があることがわかります。 これは複雑なメカニズムです。 さらに、2つのログに同時に一貫して書き込む必要があります（2フェーズコミット）。 これはさらに悪いことです。



次の図には、2つのグラフがあります。







青いグラフは、スレッドを追加したときにInnoDBがどのようにスケーリングするかを示しています。 スレッドを配布します-処理するトランザクションの数が増加します。



赤い線は、レプリケーションが有効になっていることを示します。 レプリケーションを有効にすると、スケーラビリティが失われます。 Binary Logのログは同期的に書き込まれるため、Group Binary Log Commitはこれを解決します。



下のストレージエンジン、上のレプリケーションの分離のため、これを行う必要があるのは残念です。 これはすべて悪いです。 MySQL 5.6および5.7では、この問題は解決されています。グループバイナリログコミットがあり、ウィザードは遅れることはありません。 現在、彼らはこれをレプリケーションの並列処理に使用しようとしているため、スレーブ上で同じグループからのリクエストを並行して起動できます。 それから私はあなたがこれからねじる必要があることを書きました：







2013年10月以降、大量のデータがあるため、レプリケーションは常に遅れており、誰もが動揺しています。この並列性を確認しようとしました。 まだ何かを理解していなかったのか、間違った設定をしたのか、多くの試みがあり、結果は次のようになったのでしょう。







青いグラフはMySQL 5.5です。



y軸上-スレーブのプロセッサ消費。 X軸は時間です。



このグラフでは、マスターに追い付くために複製が開始された時期と終了した時期を確認できます。 1つのスレッドで5.5が4つのスレッドで5.7の並列レプリケーションとほぼ同じように機能するという興味深い画像が判明しました。 つまり CPUはより多く消費され（緑色の線）、同じ時間に動作します。 4つのスレッド、4つのスレッドがあります。 5.7で1つのスレッドを作成すると、動作が悪くなります。 これは何らかのリグレッションであり、5.7.5で修正することを望んでいましたが、チェックしました-問題はまだ関連しています。 私のベンチマークでは、これはそうです、これは本番環境でのテストでもそうです、それは当然です。 彼らがそれを修正することを願っています。



他に何が問題です-サービスを停止せずに移行するには、ある時点で、MySQL 5.5がウィザードで起動され、5.7がスレーブで起動されます。 5.5にはGroup Binary Log Commitがありません。つまり、5.7は1つのスレッドでしか動作しません。 これは、5.7のレプリカが遅れ始め、追いつかないことを意味します。 シングルスレッド5.7レプリケーションにリグレッションがある限り、移行することはできません。5.5に座っているため、選択の余地はありません。



ここで最も興味深い部分は、私が言ったことすべてと、制限時間のためにレポートに残されたものを要約することです（3時間の資料があります）。



まず、アーキテクチャには3つのタイプのマガジンがあり、物理レベルと論理レベルでの複製があります。 物理層はページです。 PostgreSQLは、テーブルの更新、トリガーの作成、ストアドプロシージャの作成など、すべてがログを通過するため強力です。したがって、PostgreSQLの問題は少ないです。 MySQLでは、有効にしたレプリケーションのタイプに応じて、論理レプリケーションまたはクエリレベルレプリケーションを取得します。



原則として、これらの雑誌には長所と短所があるため、慎重に選択する必要があります。



なぜ彼らは強い/弱いのですか：







最初の行では*です。 私は説明します-とにかく、マスターからログをコピーする必要があり、さらにスレーブはログを削除しないように何らかの理由でマスターに尋ねることができます。



MySQLには2つの重大なペナルティ、スレッド、レプリケーションがウィザードに与える影響があります。

1. ステートメントベースのレプリケーションが機能するためのInnoDBのオプション。
2. Group Binary Log Commitがなければ、スケーリングは行われません。

MySQLの行ベースのレプリケーションはより効果的ですが、問題があります。



次に、奴隷。 PostgreSQLはディスク上に、MySQLはプロセッサ上にあります。



ディスク消費量の観点では、ここでより興味深いものになります。 たとえば、MySQLの行ベースのレプリケーション（PostgreSQLではほぼ同じ）で1日に数十テラバイトのログが取得されます。これを保存するディスクがあまりないため、ステートメントベースに座っています。 これも重要です。レプリカが遅れている場合は、ログをどこかに保存する必要があります。 この意味で、PostgreSQLはステートメントベースのレプリケーションよりも悪く見えます。



スレーブプロセッサを使用する場合、文字列を見つけやすく、クエリが適切に機能するように、スレーブに適切なインデックスを作成することが重要です。 これはかなり奇妙なメトリックです。 レプリケーション効率の観点からスレーブを最適化します。 レポートを構築するためにスレーブが必要ですが、スレーブがレポートを構築するだけでなく、追いつく時間も確保できるように設定する必要があります。 MySQLパラレルスレーブ5.6 / 5.7-期待に応えるまで正常に動作することを楽しみにしています。



もう1つの重要なトピックは、データの一貫性です。



PostgreSQLレプリカは、ウィザードのバイナリコピーです。 つまり 文字通り-マスターでの記録を停止し、レプリケーションをスレーブで終了させ、マスターとスレーブでプロセスを停止し、PostgreSQLマスターとPostgreSQLスレーブのバイナリ比較を行うと、それらが同じであることがわかります。 MySQLでは、そうではありません。 行ベースのレプリケーションは、タプルを使用した論理表現で機能します。その中で、すべての更新、挿入、削除が正しく機能し、すべてが正常に機能します。



ステートメントベースのレプリケーションでは、これは当てはまりません。 ウィザードを誤って設定し、特定のトリッキーなクエリを実行すると、異なる結果が得られる場合があります。 データベーススキーマで機能するクエリ（テーブルの作成、インデックスの作成など）の場合、それでも悲しく、常に生のクエリのようになります...ステートメントベースのレプリケーションの機能を常に覚えておく必要があります。



混合ベースでは、ストーリーはさらに興味深いものになります-これはどちらかであり、すべてを監視する必要があります。



柔軟性。 レプリケーションはより柔軟であるため、MySQLは現時点では本当に優れています。 マスターとスレーブで異なるインデックスを作成できます。データスキームを変更することもできます-必要な場合もありますが、PostgreSQLでは現在そのような可能性はありません。 さらに、MySQLにはlibslaveがあります。これは非常に強力なものであり、非常に気に入っています。 私たちの悪魔はMySQLスレーブのふりをして、常にリアルタイムで更新を取得します。 約5秒の遅延があります。 -ユーザーがバナーを見るかクリックすると、5秒後にデーモンがすべてを集約し、データベースに記録しました。 それを知ったバナーを配布する悪魔。 PostgreSQLにはそのようなツールはありません。



ただし、PostgreSQLは以下を計画しています。 まず、論理ログストリーミングレプリケーションなどがあります。これは、先行書き込みログを変換する方法です。 たとえば、このデータベースからすべてのテーブルを複製するのではなく、一部のみを複製する必要があります。 論理ログストリーミングレプリケーションにより、ウィザードはスレーブ用に残すテーブルを説明できます。



論理デコードもあります-PostgreSQL先行書き込みログの内容を視覚化する方法。 実際、スレーブで何が起こっているのか、またはWrite-Ahead Logを通じて何が起こったのかを何らかの形で印刷できる場合、これはlibslaveが行うすべてをプログラムで実装できることを意味します。 挿入、更新、削除を取得し、目的のコールバックを「ジャーク」し、変更について学習しました。 これは論理デコードです。



これからの結論は非常に興味深いです-通常のジャーナルを作成するのが最善です。 PostgreSQLには、通常のログ、すべてのデータの更新、スキームのすべての変更、および一般的にすべてのものが記録されています。 これにより、たとえば、正しく動作するレプリケーション、プロセッサではなくディスク上にのみ存在するレプリケーションなど、多くの利点が得られます。 このようなマガジンを使用すると、特定のパッチセットをエンジン自体、マスター、スレーブに追加できます。これにより、柔軟性を高めることができます。 テーブルをフィルタリングし、他のインデックスを持っています。



そして歴史的な理由から、MySQLのログは不良であることが判明しました。 MySQLはその歴史的発展の人質です。 MySQLの問題をパフォーマンスと正確さで解決するには、ストレージエンジンに関連付けられているアーキテクチャ全体を書き換える必要がありますが、これは現実的ではありません。



かなり時間がかかると思いますが、PostgreSQLは機能別にMySQLをキャッチします。



そして最後に。 レポート全体から多くのことを理解していない場合、または理解する必要がある場合でも、いずれにしても、2つの最も重要な結論を覚えておいてください。

1. レプリケーションはバックアップ（バックアップ）ではありません。
2. テーブルは2次元配列ではなく、同種の組のマルチセットです。 したがって、コンピュータサイエンスの観点からは正しいです。

このレポートは、私が多くの人々を作るのに役立ちました。

連絡先

ザビバトール

このレポートは、高負荷システムHighLoad ++の開発者の会議で行われた最高のスピーチの1つの転写です 。 現在、2016年の会議を積極的に準備しています。今年は11月7日と8日にSkolkovoでHighLoad ++が開催されます。



複製のトピックは永遠です:)今年は、2つのレポートで何らかの形でそれに触れます。

• MySQLの準備方法 / Nikolay Korolev（Badoo）;
• MySQL / Sveta Smirnov レプリケーションの効率的なデバッグ （Percona）。

また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに30以上のユニークな資料があります。 接続してください！