Hébergements Web - Migration WP Mysql > MariaDB
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Frage

Migration WP Mysql > MariaDB

Von
RomainF2
Erstellungsdatum 2023-04-12 10:12:46 (edited on 2024-09-04 13:02:00) in Hébergements Web

Salut à tous,
Je dispose d'un hébergement Perfo 1 avec un wordpress et une DB en mysql 5.7 et PHP 7.4.
Sur mon SQL Privée Web Cloud Databases, j'ai que 512 Mo de RAM et des dépassements mémoire fréquents.
J'ai donc pour projet de commander une nouvelle base SQL Privée 1 Go de RAM et de migrer ma base.
Dans la foulée je voudrais passer sur MariaDB 10.6 et PHP 8.2.
Est-ce que je pourrais a votre avis exporter ma base Mysql 5.7 et la réimporter sur MariaDB directement ? Pour la version de PHP je pensais la faire évoluer avant de migrer la base.

Y'a t-il une procédure particulière à suivre, un guide sur le sujet ?
Je trouve difficilement des infos là dessus.

Merci d'avance !
Cordialement.


6 Antworten ( Latest reply on 2023-04-14 16:58:42 Von
janus57
)

Bonjour,
A ma connaissance mariaDB est très très compatible avec Mysql.

Le seul pb que j'ai eu dernièrement est l'encodage de certaines table : utf8mb4_0900_ai_ci non pris en charge par MariaDB.
A encoder vers utf8mb4_unicode_520_ci

> When MySQL introduced utf8mb4_0900_ai_ci based on comparison and sorting rules in Unicode 9.0, MariaDB chose not to follow at the time. The new rules did not change much as Unicode's sorting and comparison rules have been pretty stable for several generations of Unicode now. Choosing the "unicode_520_ci" rules will in almost all situations have the same result and this collation can be used in both MySQL and MariaDB.

https://dba.stackexchange.com/questions/248904/mysql-to-mariadb-unknown-collation-utf8mb4-0900-ai-ci

Ok, donc a priori pas de contraintes particulière pour restaurer un Dump MYSQL sur MariaDB ?
Je pense pas avoir d'encodage utf8mb4_0900_ai_ci sur ma base.

Pour PHP 8.2 , je viens d'essayer, ça le fait pas du tout sur wordpress, ça casse toute la mise en page.
Je vais rester encore un peu en 7.3 ... :-/


ça casse toute la mise en page.


ouch. Voyez si votre theme et vos plugins sont à jour.

Bonjour Romain F2,

Comme indiqué par Fritz2cat, assurez-vous d'abord d'avoir mis tout votre site (WordPress, thèmes, extensions) à jour d'abord, puis passez en PHP 8.2 par la suite (si tous ces éléments sont bien déjà compatibles avec).

Concernant votre SQL Privé, les dépassements de mémoire OOM (Out Of Memory) peuvent avoir diverses causes :
- Les requêtes MYSQL de votre site ne ferme pas la connexion après avoir interrogé la BDD => elles restent donc en mémoire et au fur à mesure font augmenter la consommation de la RAM
- La configuration du SQL Privé : assurez-vous d'avoir bien configuré les différents paramètres de celui-ci. Pour cela vous pouvez vous référer https://docs.ovh.com/fr/clouddb/configurer-optimiser-son-serveur-de-base-de-donnees/#modifier-la-configuration-de-mon-serveur-de-bases-de-donnees à ce guide (les valeurs indiquées sur la capture d'écran sont idéales pour un SQL Privé de 512 Mo).

Je vous souhaite une belle journée.

Bonjour, merci pour votre retour.
Pour PHP 8 , mon wordpress et plugin sont à jour, mais mon thème est probablement pas compatible, donc je laisse tomber pour l'instant.
Pour la base, j'ai suivi le tuto, ma config est désormais la suivante :
local_infile : ON
autocommit : ON
max_connections : 200
event_scheduler : OFF
tmpdir : /dev/shm
max_allowed_packet : 8M
interactive_timeout : 600
sql_mode : ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
max_user_connections : 100
wait_timeout : 600
innodb_buffer_pool_size : 128M

Je vais voir si cela change quelque chose.
Pour les requêtes SQL qui se ferme pas, qu'est ce que je peut changer comme paramètre pour régler ça ?
Quand je vois dans les métriques la conso mémoire qui monte tout le temps, je me dit que c'est peut-être le cas en effet.



Quand je vois dans les métriques la conso mémoire qui monte tout le temps, je me dit que c'est peut-être le cas en effet.


Vous avez comparer les dates de dépassement et l'activité effective de votre site (stats et log) ?

De ce que j'en sais, la connexion BDD est clôturée de toute façon à la fin de l’exécution du PHP.
Avez du développement perso sur votre WP ? Ou des plugins qui ne sont pas très utilisé (peu réputé) ?

Bonjour,
Quand je regarde les logs et stats, je vois qu'un jour normal sans dépassement mémoire, j'ai entre 40 et 50 000 lignes dans le log (requêtes GET / POST) et les jours ou je suis en dépassement mémoire j'ai 60 à 65 000 requêtes.
Sur les stats en rythme de croisière je suis entre 60 et 80 hits/min toute requêtes confondues, et en pic d'activité y'a des pointes a 120 voir 160 hits. La corrélation avec les dépassement mémoire est pas évidente à première vue mais pas impossible en effet.
J'ai pas d'autre site avec un traffic équivalent pour comparer donc difficile à dire si c'est un fonctionnement normal...
Sinon, pas de développement spécifique sur le wordpress mais pas mal de plugin installés oui (64 actifs exactement), mais pour la plupart assez réputés.


Quand je regarde les logs et stats, je vois qu'un jour normal sans dépassement mémoire, j'ai entre 40 et 50 000 lignes dans le log (requêtes GET / POST) et les jours ou je suis en dépassement mémoire j'ai 60 à 65 000 requêtes.
Sur les stats en rythme de croisière je suis entre 60 et 80 hits/min toute requêtes confondues, et en pic d'activité y'a des pointes a 120 voir 160 hits.

Les hits sur des fichiers statiques (jpg, css ...) n'influence pas votre problème.
Seuls ceux qui font appel à PHP (et donc dans la majorité des cas à la BDD) posent un problème.

Si vous avez accès à un terminal (Linux, MacOs, Windows power shell ? ) vous pouvez passer vos log avec une commande du genre :
`cat access.log | egrep -v "(.gif|.jpg|.png|.swf|.ico|.txt|.xml|.css|.js|.rss|.webp|.woff|.woff2)" | wc -l`
Pour avoir une idées des hits "dynamiques"

> y'a des pointes a 120 voir 160 hits

160 hits /min tout compris c'est pas énorme.


Sinon, pas de développement spécifique sur le wordpress mais pas mal de plugin installés oui (64 actifs exactement), mais pour la plupart assez réputés.


Ok, là par contre, cela mérite de regarder. 64 plugins ça me parait énorme.
Je précise que ne suis pas webmaster mais j'héberge pas mal de Wordpress mis en place par des pro (agences web, indépendant) et je suis quasi sur qu'aucun n'approche (même de loin) un tel nombre.

Presque toujours quand je dois faire du support pour des raisons de perf, le client final avait installé n'importe quoi ou juste trop de plugins.
Je ne critique pas mais il faut avoir conscience cela à un impact important sur la consommation de RAM et les performances générale du site.

D’ailleurs en fait, constatez vous un problème de performance ou c'est juste les dépassements mémoire de votre SQL qui vous traquasse ? Car en fait tout semble bien fonctionner au final non ?

Bonjour,


ou c'est juste les dépassements mémoire de votre SQL qui vous traquasse ?

En fait dépassements == OOM Killer qui passe sur l'instance donc quand ça arrive ça doit rendre le site HS.

Sinon faite déjà le ménage dans les plugins car 64 c'est juste énorme d'autant plus si vous avez des plugins de stars & protection qui vont bien attaquer la BDD (par exemple wordfence est très consommateur selon les options activés).

Que donne vos graphiques de ressources Web ?

Cordialement, janus57

Oui le site rame a fond depuis quelques temps, il est rarement HS mais il peut faire une erreur 500 une fois de temps en temps.
Les ressources web c'est calme plat, j'ai un seul pic a 10 overloads, tout le reste du temps a zéro.
Je vais rebalayer les plugins du coup voir si je peut alléger tout ça !
Merci de votre contribution, et bon WE !

Bonjour,


il peut faire une erreur 500 une fois de temps en temps.

== HS pour moi

Cordialement, janus57