Teilen Sie zwei Probleme mit, die bei der Verwendung von Mariadb aufgetreten sind

Auswahl neuer MySQL-Versionen

In den frühen Tagen verwendete das Unternehmen hauptsächlich die MySQL5.5-Version. In diesem Jahr haben wir das Datenbankkonfigurationscenter aufgebaut und hauptsächlich die MySQL5.6-Version beworben, die sowohl Leistung als auch Leistung bietet Mit bestimmten Verbesserungen kann mysql5.6 auch gtid unterstützen, aber es kann nicht online zwischen dem gtid-Modus und dem normalen Modus wechseln. Gleichzeitig ist die Synchronisierungsleistung von 5.6 immer noch unbefriedigend und es kann nur die parallele Replikation gestartet werden Es ist schwierig, eine solche Garantie im Geschäftsleben zu haben. Sobald der Schreibvorgang intensiv ist, stellt die langsame Synchronisierung ein ernstes Problem dar.

Daher habe ich kürzlich über ein Upgrade von MySQL nachgedacht. Das erste Problem, mit dem ich beim Upgrade von MySQL konfrontiert bin, besteht darin, eine geeignete Version auszuwählen. Zunächst wird MySQL 5.7 in mehreren offiziellen Versionen veröffentlicht und kann für den Einsatz in einer formellen Umgebung in Betracht gezogen werden. Deshalb haben wir einen Online-Vergleichstest durchgeführt und festgestellt, dass zwischen MySQL5.7 und unserer Online-Version von MySQL5.6 ein großer Leistungsunterschied besteht (vielleicht weil einige Parameter nicht richtig angepasst wurden, 5.7 ist tatsächlich viel komplizierter).

Gleichzeitig hat das Unternehmen in letzter Zeit häufig etwas Protokollspeicherung festgestellt. Die meisten von ihnen verwenden die Innodb-Engine, was andererseits eine Verschwendung von Kapazität darstellt, da die Standard-MySQL-Serverkapazität unseres Unternehmens ca. ist 1,3T, für einige große Unternehmen mit Kapazitätsanforderungen gibt es auch Kapazitätsengpässe. Wenn Sie Daten über einen längeren Zeitraum aufbewahren möchten, wird es schwierig sein, den Bedarf zu decken. Deshalb nutzen wir diese Gelegenheit, um gemeinsam darüber nachzudenken. Derzeit unterstützen sowohl Percona als auch Mariadb Tokudb, und Mariadb 10.2 oder 10.3 plant auch die Unterstützung von Myrocks.

Also habe ich mich für einen Vergleichstest entschieden und mich für Percona 5.7.14, Mariadb 10.1.18 und unser Online-MySQL 5.6 für einen Vergleichstest entschieden und den Stresstest bestanden.

Zunächst wird die Innodb-Engine verwendet:

Die Testergebnisse von Mariadb und MySQL5.6 liegen nahe beieinander

Die Leistungsergebnisse von Percona 5.7.14 und dem offiziellen MySQL5.7 ist im Vergleich zu MySQL 5.6 ähnlich. Es gibt eine gewisse Lücke seit MySQL 5.6 (das Entfernen von performance_schema ist besser, aber es gibt immer noch eine Lücke).

Die Testergebnisse mit der Tokudb-Engine weichen von den offiziellen Behauptungen ab. Bei Verwendung von Snappy-Komprimierung ist Insert etwa 1/4 langsamer als Innodb und Update nur etwa die Hälfte von Innodb. Da die Leistung von Percona schlechter ist, wird sie nicht berücksichtigt.

Schließlich habe ich mich für Mariadb 10.1.18 entschieden und ein Unternehmen online bereitgestellt. Nachdem ich dieses Unternehmen langsam ausprobiert hatte, wurde es nach und nach beworben.

Einige Fallstricke bei der Verwendung von Mariadb

Bei der Verwendung von Mariadb bin ich auf viele Probleme gestoßen:

1. Probleme mit der Synchronisierungsleistung:

Unsere Geschäftsspitze erreichte mehr als 9.000 Schreibvorgänge/Sekunde. Das erste Problem, mit dem wir konfrontiert waren, war, dass die Anzahl der Slave-Synchronisierungen bisher nicht mithalten konnte Die Anzahl der Threads wurde auf 16 Threads erhöht, die kaum aufholen können. Sobald die Datenbank jedoch für eine Weile angehalten wird, besteht die Möglichkeit, dass sie nie mehr aufholen kann. Als ich fast verzweifelt war, las ich den offiziellen Artikel von Mariadb (https://mariadb.com/kb/en/mariadb/parallel-replication/). Die parallele Replikation von Mariadb unterstützt mehrere Modi, darunter In-Order und Es gibt zwei Typen Unser Unternehmen unterstützt jedoch den In-Order-Modus. Im In-Order-Modus werden zwei Typen unterstützt: Konservativ und Optimistisch stellt die Reihenfolge der Dinge strikt sicher, was wahrscheinlich dem Prinzip des Gruppen-Commits in 5.7 ähnelt, während im optimistischen Modus so viele Sitzungen wie möglich während der Replikation gestartet werden und Konflikte nicht behandelt werden, bis Konflikte entdeckt werden. Ich habe Optimistic entschieden ausprobiert und es war sehr leistungsstark, mit einer maximalen Synchronisationsgeschwindigkeit von 14.000 Mal/Sekunde.

2. „Speicherleck“

Die Systembereitstellungsstruktur ist: Zwei MariaDBs werden als Master-Master-Replikation verwendet, und eine selbst entwickelte verteilte Datenbank wird vorne und auf der Geschäftsseite bereitgestellt Stellt eine Verbindung zum Datenbankprozess der verteilten Datenbank her. Nachdem das System einige Tage lang online war, stellte sich heraus, dass die Hauptdatenbank aus unerklärlichen Gründen hängen blieb. Glücklicherweise gibt es eine verteilte Datenbank, und diese wechselt automatisch zu einer anderen Hauptdatenbank Datenbank, ohne dass die Geschäftsseite es bemerkt. Als ich das Kernel-Protokoll überprüfte, stellte ich fest, dass es sich um OOM handelte und der Kernel MySQL beendete.

Also habe ich verschiedene Versuche gestartet, darunter das Entfernen der Tokudb-Engine-Konfiguration und den Wechsel zu Mariadb 10.1.19. Ich habe sie alle ausprobiert, aber schließlich ist die Hauptdatenbank abgestürzt. Zufällig stoppte ich den Slave in der Hauptbibliothek und stellte fest, dass der Speicher der Hauptbibliothek plötzlich stark abnahm und der Speicher nicht mehr zunahm. Als ich jedoch den Slave in der Hauptbibliothek startete, stellte ich fest, dass der Speicher stark abnahm allmählich wieder zugenommen. Dieses Phänomen ist dem Speicherzuweisungsmechanismus im MySQL-Thread sehr ähnlich (mem_root-basierte Speicherzuweisung, alles wird freigegeben, wenn der Thread gestoppt wird), sodass zunächst vermutet wird, dass dies die Ursache ist. Ich habe festgestellt, dass es wie bei den anderen MariaDB im Dual-Master kein Problem mit der Speichererweiterung geben wird.

Nachdem wir das obige Phänomen entdeckt hatten, begannen wir mit dem Debuggen des Codes. Verwenden Sie gdb, um eine Mariadb zu starten, und die andere mit gewöhnlichen Befehlen. Diese beiden Bibliotheken werden zu Dual-Mastern gemacht:

Die erste Methode Situation: Beim Testen als Slave-Bibliothek werden die empfangenen Binlog-Ereignisse

Fügen Sie eine Datenzeile in Mariadb ein, die durch einen normalen Befehl gestartet wurde. Die Reihenfolge von gdb zum Anzeigen der empfangenen Ereignisse ist wie folgt:

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

Zweiter Fall: Beim Testen als Hauptbibliothek wurde das Binlog-Ereignis empfangen

在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. 数据库设计那些事

Das obige ist der detaillierte Inhalt vonTeilen Sie zwei Probleme mit, die bei der Verwendung von Mariadb aufgetreten sind. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!