Sélection de la nouvelle version de MySQL

Au début, l'entreprise utilisait principalement la version mysql5.5. Cette année, nous avons construit le centre de configuration de la base de données et avons principalement promu la version mysql5.6, qui offre à la fois des performances et des performances. Avec certaines améliorations, mysql5.6 peut également prendre en charge gtid, mais il ne peut pas basculer entre le mode gtid et le mode normal en ligne. Dans le même temps, les performances de synchronisation de 5.6 sont toujours insatisfaisantes et il ne peut démarrer la réplication parallèle que dans ce cas. de plusieurs bases de données. Il est difficile d'avoir une telle garantie en entreprise, donc une fois l'opération d'écriture intensive, la synchronisation lente sera un problème sérieux

Par conséquent, j'ai récemment envisagé de mettre à niveau MySQL ; La première chose à laquelle je suis confronté lors de la mise à niveau de MySQL est Le problème est de choisir une version appropriée. Tout d'abord, nous envisageons d'utiliser mysql5.7 qui a été publié dans plusieurs versions officielles cette année. Il est actuellement utilisé dans un large éventail d'applications. et peut être envisagé pour une utilisation dans un environnement formel. Nous avons donc effectué un test de comparaison en ligne et avons constaté qu'il y avait un grand écart de performances entre mysql5.7 et notre version en ligne de mysql5.6 (c'est peut-être parce que certains paramètres n'étaient pas bien ajustés, la 5.7 est en effet beaucoup plus compliquée).

Dans le même temps, l'entreprise a fréquemment constaté récemment un stockage de journaux. La plupart d'entre eux utilisent le moteur innodb, ce qui constitue un gaspillage de capacité, car la capacité du serveur MySQL standard de notre entreprise est d'environ . 1,3T, pour certaines grandes entreprises ayant des besoins en capacité, il existe également des goulots d'étranglement en capacité. Si vous souhaitez conserver les données pendant une longue période, il sera difficile de répondre à la demande. Nous profitons donc de cette occasion pour réfléchir à cela ensemble. Actuellement, Percona et Mariadb prennent en charge Tokudb, et Mariadb 10.2 ou 10.3 prévoit également de prendre en charge Myrocks.

J'ai donc décidé de faire un test comparatif et j'ai choisi Percona 5.7.14, Mariadb 10.1.18 et notre MySQL 5.6 en ligne pour des tests comparatifs et j'ai réussi le test de résistance.

Tout d'abord, le moteur Innodb est utilisé :

Les résultats des tests de Mariadb et MySQL5.6 sont proches

Les résultats de performances de Percona 5.7.14 et les résultats officiels MySQL5.7 est similaire à MySQL 5.6. Il y a un certain écart depuis MySQL 5.6 (il est préférable de supprimer performance_schema, mais il y a toujours un écart).

Les résultats des tests utilisant le moteur Tokudb sont différents des affirmations officielles. Lors de l'utilisation d'une compression rapide, l'insertion est environ 1/4 plus lente qu'innodb et la mise à jour n'est qu'environ la moitié d'innodb. Les performances de Percona sont pires, elles ne seront donc pas prises en compte.

J'ai finalement sélectionné Mariadb 10.1.18 et déployé une entreprise en ligne Après avoir lentement testé cette entreprise, elle a été progressivement promue.

Quelques pièges rencontrés lors de l'utilisation de Mariadb

Dans le processus d'utilisation de Mariadb, j'ai rencontré de nombreux problèmes Voici deux problèmes majeurs que j'ai rencontrés pour votre référence :

1. Problèmes de performances de synchronisation :

Notre période de pointe d'activité a atteint plus de 9 000 opérations d'écriture/seconde. Le premier problème que nous avons rencontré était que les performances de synchronisation ne pouvaient pas suivre. a été augmenté à 16 threads, ce qui peut à peine rattraper son retard. Cependant, une fois que la base de données est arrêtée pendant un certain temps, elle risque de ne jamais pouvoir rattraper son retard. Alors que j'étais presque désespéré, j'ai lu l'article officiel de mariadb (https://mariadb.com/kb/en/mariadb/parallel-replication/). La réplication parallèle de Mariadb prend en charge plusieurs modes, dont dans l'ordre et il en existe deux types. de dans le désordre. Cependant, notre entreprise prend en charge le mode dans le désordre, donc le mode dans le désordre n'est pas pris en charge : Conservateur et Optimiste. garantira strictement l'ordre des choses, ce qui est probablement similaire au principe de validation de groupe dans la version 5.7 ; en mode optimiste, autant de sessions que possible seront démarrées pendant la réplication, et les conflits ne seront pas traités tant qu'ils ne seront pas découverts. J'ai essayé Optimistic de manière décisive et il était très puissant, avec une vitesse de synchronisation maximale de 14 000 fois/seconde.

2. "Fuite de mémoire"

La structure de déploiement du système est la suivante : deux MariaDB sont utilisées comme réplication maître-maître, et une base de données distribuée auto-développée est déployée devant, et le côté commercial se connecte au processus de base de données de base de données distribuée. Après que le système soit resté en ligne pendant quelques jours, il a été constaté que la base de données principale raccrochait inexplicablement. Heureusement, il existe une base de données distribuée et elle basculera automatiquement si la base de données principale MariaDB raccroche, elle passera automatiquement à une autre base de données principale. base de données sans que le côté commercial ne s'en aperçoive. En vérifiant le journal du noyau, j'ai découvert qu'il s'agissait d'un MOO et que le noyau avait tué MySQL.

J'ai donc lancé diverses tentatives, notamment la suppression de la configuration du moteur Tokudb et le passage à Mariadb 10.1.19. Je les ai toutes essayées, mais finalement la base de données principale est tombée en panne. Par hasard, j'ai arrêté l'esclave sur la bibliothèque principale et j'ai constaté que la mémoire de la bibliothèque principale avait soudainement beaucoup diminué et que la mémoire n'augmentait plus. Cependant, une fois que j'ai démarré l'esclave sur la bibliothèque principale, j'ai constaté que la mémoire. progressivement augmenté à nouveau. Ce phénomène est très similaire au mécanisme d'allocation de mémoire dans le thread mysql (allocation de mémoire basée sur mem_root, tout sera libéré lorsque le thread est arrêté), on soupçonne donc initialement que c'est la cause. J'ai trouvé que comme les autres MariaDB du double maître, il n'y aura pas de problème d'augmentation de la mémoire.

Après avoir découvert le phénomène ci-dessus, nous avons commencé à déboguer le code. Utilisez gdb pour démarrer un mariadb, et l'autre avec des commandes ordinaires. Ces deux bibliothèques sont transformées en doubles maîtres :

Le premier. méthode Situation : lors du test en tant que bibliothèque esclave, les événements binlog reçus

Insérer une ligne de données sur mariadb démarrée par une commande normale L'ordre de gdb pour afficher les événements reçus est le suivant :

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

Copier après la connexion

Deuxième cas : lors du test en tant que bibliothèque principale, l'événement binlog a été reçu

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

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

Copier après la connexion

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!