MySQLからTarantoolへのレプリケーション

こんにちは、Habr！ 今日は、Tarantool Meetupに関する私のレポートに基づいて書かれた記事を共有します。 MambaがTarantoolの使用を開始した理由についての小さな物語。 MySQLからTarantoolへのレプリケーションを行うのはなぜですか？ 最初の理由は、ある時点でMySQL 5.7への切り替えを開始する必要があったが、MySQL 5.6のサーバーでアクティブに使用されるハンドラソケットがなかったためです。 Perconaチームにも連絡を取り、5.6がcハンドラソケットの最新バージョンであることを確認しました。

2番目の理由は、Tarantoolの試用を開始したことと、作業の速度が気に入ったためです。memcacheとTarantoolをキー/値ストレージとして比較したところ、同じハードウェアでパフォーマンスが0.6〜0.3 ms向上しました。 相対的な観点では、Tarantoolは2倍の速さです。絶対的な観点では、それほどクールではありませんが、それでもです。 3番目の理由は、現在の構造を完全に保存したいという願望です。MySQLServerマスターとそのスレーブがあり、何も書き直したくありませんでした。 ハンドラソケットを使用するMySQL 5.6スレーブの代わりに、他の何かを適用し、巨大なアーキテクチャ全体を完全に書き換えないようにするにはどうすればよいでしょうか？

Mail.Ru Groupチームには、独自の目的で作成したレプリケーターがあることがわかりました。 元々、MySQLからTarantoolにデータを複製することが彼らのアイデアでした。 1.7ではなくMySQL 5.1とTarantool 1.5で動作するため、やり直さなければならないコードを依頼しました。 レプリケーターは、オープンソース開発のlibslaveを使用して、MySQL Masterサーバーからイベントを読み取ります。 完全に静的にコンパイルされ、システムmysql libを使用しないレプリケーター。 MySQLからTarantoolへのレプリケーターは、BSDライセンスの下でオープンソースで利用できます。 完全に無料で使用できます。 ソースは次のとおりです。https ： //github.com/tarantool/mysql-tarantool-replication

このレプリケーションの制限

まず、マスターのbinログは行ベースのみである必要があります。 ステートメントも混合も行いません。行ベースのみです。 第二に、レプリケーターはTarantoolの特定のモジュールではなく、個別のデーモンです。 つまり、このツールは、原則として、TarantoolまたはMySQLのいずれにも関連付けられていません。 第三に、必要であれば、1人のマスターが10個のスレーブを持っているとしましょう。10個のデーモンを実行する必要があります。 1つのレプリケーターは、1つのTarantoolでのみ複製できます。 そして第4に、レプリケーターはMariaDBで動作しません。 5.6と5.7の両方で試してみましたが、これはOracleからのビルドまたはPerconaのビルドのいずれかであり、歴史的にはPerconaのバージョンを使用しています。 MariaDBのレプリケーションプロトコルが変更されました。

レプリケーションの仕組み

MySQLはTarantoolを知らず、TarantoolもMySQLを知りません。 レプリケーターはbinログをMySQLマスターから読み取り、これはすべてTarantoolに書き込まれます。

レプリケーターは何ができますか？

起動時に、レプリケーターは設定に基づいてマスターからデータを完全に取得します。これはどのデータベース/テーブルを複製する必要があるかを示します。つまり、起動するには、空のスペースを持つタランチュラを取得するだけです。これは非常に便利です。

システム管理者は、レプリケーションがまったく機能しているかどうか、レプリケーターが現在読み取っているビンログ、その位置が何であるか、もちろんこれを理解する必要があります。 別のスペースがあり、そこには3つの値のみがあります。ビンのログ名と現在読み取られている位置です。つまり、通常のスレーブ状態の表示に似ています。

10.5.2.17:5000> box.space.ReplicationLog:select() [0, 'db-bin.024218', 916925355]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

レプリケーターを展開した後、2つのサーバーでのみ実行される7つのTarantoolインスタンスを展開しました。1つのTarantoolインスタンスではすべてのマシンコアを利用できないためです。 タランチュラのアーキテクチャを少し思い出してみましょう。1つのインスタンスは3つのコアから消費できます。1つ以上のコア-ネットワーク、正確に1つのコア-トランザクション部分、正確に1つのコア-walファイルで動作します。

負荷

レプリケーターが起動し、ハンドラーソケットが動作するMySQLスレーブの負荷が急激に低下しました-ほぼゼロになりました。

その後、現在の8つのMySQLスレーブサーバーの代わりに1つだけを残そうとしました。すでに1つのサーバーが負荷を完全に保持していました。 MySQLスレーブサーバーを完全に放棄したのではなく、ハンドラソケットなしで機能するクエリを残しました。つまり、完全に5.7に切り替えることができます。 その結果、少なくとも7台のサーバー、それらで動作するエンタープライズSSDドライブ、ラックスペース、電気、およびお金を節約しました。

応答時間について興味深いことは何ですか？ Mambaには独自のBTPオープンソース製品があります。ここにグラフがあります。

ハンドラソケットには非常に珍しいAPIがあります。 最初にConnectメソッド、次にOpen Indexメソッド、次にExecuteメソッドを呼び出す必要があります。 3つのメソッドすべての合計時間が図に示されています。ハンドラソケットへの要求の期間は1秒に達する可能性があります。

そして今ではすべてが同じですが、マスターから同じデータベースが複製されるTarantoolのサーバーでは：

理由は非常に単純です。Tarantoolはインメモリデータベースであり、MySQLはSSDで動作し、バッファプールサイズで割り当てられるバッファメモリはデータベースサイズよりも少なくなりました。 ここには完全なインメモリがあり、すべてのインスタンスでも、wal-filesはオフになっています、つまり、ディスクでの作業はなく、メモリのみ、戦闘要求に行かない個別のインスタンスがあり、wal-filesも含まれていますスナップショットはそれらから作成されます。

自転車ですか？

他の誰かがこれについてすべて話していたら、私は自問します。 「しかし、あなたは自転車を発明しましたか？ MySQLのユーザーは、Tarantoolで何かを複製しています。 はい、5.7にアップグレードしたいので、ハンドラソケットをドロップすることを考えています。 しかし、それは何のためですか？ ハンドラソケットなしでプルしない場合は、もう少しサーバーを追加します。 確実にインメモリデータベースが必要な場合は、ヒープテーブルを作成するか、データベースファイルをTMPFSに転送し、シンボリックリンクを作成すると、すべてのテーブルが再びメモリに格納され、すべて正常に動作します。

しかし、これはそうではありません。

レプリケーターの主な機能はこれです。 たとえば、レプリケートするマスター上にあるデータベースには約100個のテーブルがありますが、スレーブではすべてのテーブルが役に立たないため、必要なテーブルの数はわずか7個です。 したがって、過剰なデータの複製にリソースを費やしたくありません。 MySQLでは、これらの7つのテーブルを複製するように指定できます。 しかし、7つのテーブルに120のフィールドがあり、スレーブでのみ使用されるクエリの場合、120のフィールドのうち21だけが必要であると仮定します。 MySQLでは、7つのテーブルすべてを複製しますが、この場合は約80 GBのメモリを占有します。 また、レプリケーターでは、これらのテーブルのフィールドセットのみを指定できます。つまり、7つのテーブルから120フィールドではなく、21フィールドがレプリケートされ、Tarantoolでは20 GBを占有します。

レプリケーターの別の機能：実際、これらの7つのテーブルのすべてのフィールドは1つのスペースにマージされます。つまり、結合せずに1つのクエリで選択できます。

出力は何ですか？

Tarantoolは非常に高速です。 私は彼がMySQLよりも有利であることを示すグラフを示しました-最大3回。

私たちが持っているTarantoolのレプリケーションは、MySQLよりも速く動作します。そのためです。 私たちがそれを開始したとき、すぐに生じた最初の質問は、複製が一貫しているかどうかでした。 私たちは非常にシンプルなPHPスクリプトを作成しました。このスクリプトは、1か月でアクティブなオーディエンスを獲得し、MySQLマスターとTarantoolスレーブに調和します。 アクティブなオーディエンスをアンロードするためのこのスクリプトは、1秒未満前に登録したユーザーを使用することが判明した場合がありました。 MySQLスレーブではまだ存在していませんが、Tarantoolでは既に存在していましたが、MySQLのSlave in Showスレーブステータスではラグは常にゼロですが、スレーブが遅れることはありません。 しかし同時に、情報ははるかに高速にTarantoolに届きます。 繰り返しますが、Tarantoolは完全なインメモリベースです。

タランツールの利点

MySQLサーバーから電源ケーブルを引き出してから、サーバーを再起動するとどうなりますか？ 開始時に、InnoDBリカバリプロセスが開始され、その結果、データベースが復元されます。 しかし、コントローラーがディスクへの適切な情報の書き込みを停止した時点で、コントローラー障害のためにサーバーがカーネルパニックにクラッシュし、再起動後のinnodbリカバリプロセスがCore Dumpで終了することが何度か起こりました。 Tarantoolでは、ログの先読みメカニズムが非常によく考えられているため、何らかの理由でコントローラーがwal-fileにナンセンスを書き込んだとしても、Tarantoolが上昇しないため、単にwal-fileを破棄します。 または、ファイルを開いて、Tarantoolが起動するまで1行ずつ記録データを削除します。 さらに、wal-fileに記録されるトランザクションの必要な数、少なくとも1つのトランザクションを指定できます。 上記で引用したMySQLの例は、サーバーハードウェア障害の結果であり、通常の状態ではinnodbリカバリは時計のように機能します。

また、Tarantoolが非常にシンプルであることも気に入っています。 そこではすべて、何をどのように行うかが明確です。 MySQLの新しいバージョンが出てきたとしましょう。更新しましたが、起動しません。 エラーログに登り、理解します。 my.cnfの一部の設定は既に廃止されています。 ドキュメントを開いて、まだ多くの設定があることを確認します。次に、パフォーマンスを改善するために新しいmy.cnfを記述する方法を理解する必要があります。 タランツールにはこれはありません。 ここではすべてがシンプルで明確で、最小限の設定です。

Tarantoolとの共同作業で次に楽しんだのは、クールなコミュニティです。 Telegramにはチャットルームがあり、Denis Anikinから招待状を受け取って、質問に答えてすぐにバグを修正できます。

Tarantoolスナップショットは素晴らしいです。 このメカニズムは非常に速い速度で動作します-800 Mbit /秒、場合によっては1 Gbitです。 1つのファイルに順番に書き込まれます。 ここではスーパーディスクは必要ありません。最も安価なSATAでも、すべてが非常に迅速かつ適切に機能します。 20ギガバイトのベースのスナップショットを作成するのに5分もかかりません。 私はチェックしましたが、MySQLではずっと遅くなりました。

短所

最初の最大の欠点は、特にMySQLの後にTarantoolを使用し始めた場合、Tarantoolの大文字と小文字を区別するインデックスが非常に不便であることです。

2番目の欠点はコンソールです。 たとえば、MySQLでは、レプリケーションが機能することを理解するにはどうすればよいですか？ スレーブステータスの表示を2回記録し、数字が実行されていることを確認しました。 同時に、MySQLコンソールで、Show slaveステータスが2回ではなく1回満たされます。 Show slave statusを100回連続で記入しても、History MySQLコンソールでこれを1回だけ行ったことを覚えています。 ただし、Tarantoolでは、Enterを100回入力しようとすると、コンソールでEnterを100回入力できます。繰り返し押す前の状態にスクロールしてスクロールすると、苦しめられます。

おわりに

Tarantoolは使用するのに本当に良い製品です。 はい、欠点がありますが、製品は開発中です。 MySQLからのレプリケーションが登場した後、さらに速く開発されることを願っています。 もちろん、タランツールの最も重要な利点はその速度です。 継続する。