MySQL の新バージョンの選択

当初、当社は主に mysql5.5 バージョンを使用してデータベース構成センターを構築し、主に mysql5.6 バージョンを推進しましたが、パフォーマンスと機能はある程度向上しました。、mysql5.6 も gtid をサポートしますが、オンラインで gtid モードと通常モードを切り替えることはできません。同時に、5.6 の同期パフォーマンスは、複数の DB の場合にのみ可能です。ビジネスで行うのは確実に難しいため、書き込み操作が集中すると、同期の遅さが深刻な問題になります

そこで、最近 MySQL をアップグレードするときに直面する最初の問題の 1 つは、まず、mysql5.7 を使用することを検討します。今年、5.7 のいくつかの正式バージョンがリリースされ、現在幅広いアプリケーションで使用されており、正式な環境での使用を検討できます。そこで、オンライン比較テストを実施したところ、mysql5.7 とオンラインバージョンの mysql5.6 の間にパフォーマンスに大きな差があることがわかりました (おそらく、一部のパラメーターが適切に調整されていなかったためでしょう。実際、5.7 ははるかに複雑です)。

同時に、当社では最近、ログストレージのほとんどが innodb エンジンを使用しているのをよく見かけますが、一方で、当社の標準的な mysql サーバーの容量は約 1.3 トンであるためです。大容量を必要とする一部のビジネス一般に、データを長期間保持したい場合、その需要を満たすのは困難です。したがって、この機会を利用して、これについて一緒に検討してみます。現在、Percona と Mariadb は両方とも Tokudb をサポートしており、Maridb 10.2 または 10.3 も Myrocks をサポートする予定です。

そこで、比較テストを行うことにし、Percona 5.7.14、Maridb 10.1.18、およびオンライン MySQL 5.6 を比較テスト用に選択し、ストレステストに合格しました。

まず第一に、Innodb エンジンが使用されます:

Mariadb と MySQL5.6 のテスト結果は近いです

Percona 5.7.14 と公式 MySQL5.7 のパフォーマンス結果は似ており、一定のギャップがありますMySQL5.6との比較(少しperformance_schemaを削除した方が良いですが、ギャップがあります)。

Tokudb エンジンを使用したテスト結果は、公式の主張とは異なります。Snappy 圧縮を使用した場合、挿入は innodb よりも約 1/4 遅く、更新は innodb の約半分にすぎません。 Perconaの方が性能が悪いので考慮外となります。

最終的に Mariadb 10.1.18 を選択し、オンラインでビジネスを展開しました。このビジネスをゆっくり試した後、徐々に推進されました。

Maridb を使用する際のいくつかの落とし穴

Mariadb を使用する過程で、私が遭遇した 2 つの大きな問題を参考までに紹介します:

1. ビジネスのピーク期間が 2020 年を超えました。 9,000 回の書き込み操作/秒。最初の問題は、スレーブ同期スレッドの数が 16 スレッドに増加し、データベースがしばらく停止すると、同期のパフォーマンスが追いつかないことでした。、更新されなくなる可能性があります。絶望的になったとき、mariadb の公式記事 (https://mariadb.com/kb/en/mariadb/Parallel-replication/) を読みました。Mariadb の並列レプリケーションは、インオーダーと 2 つのモードをサポートしています。ただし、当社のビジネスはインオーダーをサポートしているため、インオーダーモードでは、Conservative と Optimistic の 2 つのタイプがサポートされています。デフォルトでは、Conservative モードがこれです。物事の順序が厳密に保証されます。これは、おそらく 5.7 のグループコミットの原則に似ています。オプティミスティックモードでは、レプリケーション中にできるだけ多くのセッションが開始され、競合が検出されるまで競合は処理されません。思い切ってOptimisticを試してみたところ、最大同期速度14,000回/秒と非常に強力でした。

2.「メモリリーク」

システムの展開構造は、2つのMariaDBをマスター-マスターレプリケーションとして使用し、その前に自社開発の分散データベースを展開し、ビジネス側は分散データベースプロセスに接続します。システムが数日間オンラインになった後、メインデータベースが原因不明でハングアップすることがわかりました。幸いなことに、分散データベースがあり、MariaDB メインデータベースがハングアップすると、自動的に別のメインデータベースに切り替わります。ビジネス側が気付かないうちにデータベースを構築します。カーネルログを確認すると、OOM であり、カーネルが MySQL を強制終了したことがわかりました。

そこで、さまざまな試みを開始し、Tokudb エンジン構成を削除し、Maridb 10.1.19 に変更しましたが、最終的にメインデータベースがクラッシュしました。たまたまメインライブラリのスレーブを停止したところ、メインライブラリのメモリが急激に減り、メモリが増えなくなったのですが、メインライブラリのスレーブを起動するとメモリが増えていることが分かりました。また徐々に増えていきました。この現象は、mysql スレッドのメモリ割り当てメカニズム (mem_root ベースのメモリ割り当て、スレッドが停止するとすべて解放される) に非常に似ているため、最初はこれが原因であると考えられます。デュアルマスター内のもう一方の MariaDB と同様に、メモリ増加の問題が発生しないことがわかりました。

上記の現象を発見した後、gdb を使用して 1 つの mariadb を起動し、もう 1 つのライブラリを通常のコマンドで起動します。

最初の状況: スレーブライブラリとしてテストするとき。受信した binlog イベントの状況

通常のコマンドで起動した mariadb にデータ行を挿入し、受信したイベントを表示する gdb の順序は次のとおりです:

### i ) Gtid_log_event
### ii) Table_map_log_event
### iii) Write_rows_log_event
### iv) Xid_log_event

ログイン後にコピー

2 番目のケース: メインライブラリとしてテストする場合、受信した binlog イベント

在gdb启动的mariadb上插入一行记录，然后gdb观察接收到的事件为：

### 1）Rotate_log_event
### 2）Gtid_list_log_event
### 3）Rotate_log_event

ログイン後にコピー

Rotate_log_event事件是虚拟出来的，用于让主库跟上从库的同步位置，这基本上是一个空事件，没有做任何处理，所以初步怀疑是在处理Gtid_list_log_event事件的时候，出现了问题。

反复查看Gtid_list_log_event::do_appy_event函数中的调用情况，发现确实有些方法会调用thd->alloc来分配内存，但是没有回收，所以造成内存不断的增大，我考虑了一下，因为是主库对于同步性能要求也不高，所以在Gtid_list_log_event::do_apply_event函数的最后加了一行代码：free_root(thd->mem_root, MYF(MY_KEEP_PREALLOC)); 重新编译后，跑了一天，内存终于稳定了。

由于目前发现只有主库有该事件，主库同步处理性能要求不高，所以暂时先这样用着了。不知道mariadb官方版本什么时候会优化一下。

总体来看，Mariadb还是比较适合我们公司的，它有最新的功能、特性能够给我们提供很多解决方案。Tokudb可以解决日志型存储的问题；连接池可以解决大量连接情况下性能地下的问题；审计插件提供安全方面的审核；slave并发模式能够提供高性能的复制能力。除了这些常见功能以外，Mariadb还提供了Cassandra插件、图数据库插件等等，这些都给我们给业务的服务增加了想象力。

【相关推荐】

1. 免费mysql在线视频教程

2. MySQL最新手册教程

3. 数据库设计那些事

以上がMariadb の使用時に発生した 2 つの問題を共有しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。