Nous avons une douzaine de serveurs SQL qui tournaient sous mysql 5.5, l'upgrade debian/stretch à imposé la migration sur mariadb 10.0, résultat les requêtes de recherches de notre application on nécessité l'ajout d'un /tmp de 100Go (sur des machines dont la racine fait 10Go, + volume séparé pour le /var/lib/mysql) car le parser analyse mal les requêtes et génère des fichiers temporaires énormes (et donc des temps de requêtes supérieurs a 3 minutes).
Accessoirement les saturations de /tmp entrainement des blocages d'écritures des relay-logs, avec corruption, alors même que le relay-logs n'est pas sur la même partition.
Pour l'instant mes tests montrent que seul un passage à mariadb 10.4 permet de retrouver un parseur digne de mysql 5.5 mais il est tout juste sorti et je n'ai pas encore suffisamenet analysé les impacts
[^] # Re: Mariadb
Posté par -=[ silmaril ]=- (site web personnel) . En réponse au message sécuriser un serveur web auto hébergé. Évalué à 2.
source: experience professionnelle
Nous avons une douzaine de serveurs SQL qui tournaient sous mysql 5.5, l'upgrade debian/stretch à imposé la migration sur mariadb 10.0, résultat les requêtes de recherches de notre application on nécessité l'ajout d'un /tmp de 100Go (sur des machines dont la racine fait 10Go, + volume séparé pour le /var/lib/mysql) car le parser analyse mal les requêtes et génère des fichiers temporaires énormes (et donc des temps de requêtes supérieurs a 3 minutes).
Accessoirement les saturations de /tmp entrainement des blocages d'écritures des relay-logs, avec corruption, alors même que le relay-logs n'est pas sur la même partition.
Pour l'instant mes tests montrent que seul un passage à mariadb 10.4 permet de retrouver un parseur digne de mysql 5.5 mais il est tout juste sorti et je n'ai pas encore suffisamenet analysé les impacts