Written by Cyril

Après la migration HTTP, c’est au tour de la (très attendue) migration du serveur SQL. Depuis le mois de juin dernier, une forte croissance des requêtes SQL a rendu notre serveur actuel moins véloce, ce qui a un effet immédiat sur la performance de vos sites.

Le nouveau serveur SQL a :

• 12 fois plus de RAM ;
• 4 fois plus de CPUs (chacun étant aussi plus rapide) ;
• des disques SSD.

Autrement dit, ça devrait aller vite, très vite.

Le changement de serveur est également l’occasion de mettre à jour :

• MySQL en version 5.1.39 (depuis la 5.0.32) ;
• PostgreSQL en version 8.4.1 (depuis la 8.3.5) ;
• PostGIS en version 1.3.6 (depuis la 1.3.3).

Ces mises à jour introduisent nécessairement de nombreuses petites incompatibilités mineures. Nous n’avons repéré aucune incompatibilité notable (comme celle de la version 8.3 de PostgreSQL). Dans l’immense majorité des cas, vos applications continueront à fonctionner tout à fait normalement.

Néanmoins, comme à notre habitude, nous vous laisserons la possibilité de tester vos applications avec le nouveau serveur avant de le mettre en production. C’est une simple mesure de précaution, sûrement pas une obligation. Autrement dit, si vos applications ne peuvent pas se permettre d’être hors service, vous devriez tester. Si vous utilisez PostGIS, vous devriez également tester. Sinon, ce n’est probablement pas nécessaire.

Attention, avant de tester, lisez bien tout ce qui suit :

• le nouveau serveur SQL est accessible via mysql2.alwaysdata.com et postgresql2.alwaysdata.com ;
• les données ont été importées depuis le serveur de production ce lundi 12 octobre. Le nouveau serveur contient donc des données périmées qui ne seront pas remises à jour. Le but est simplement de vous permettre d’avoir une base réelle sur laquelle tester vos applications ;
• il n’y a aucun mécanisme de synchronisation ni dans un sens (ancien -> nouveau) ni dans l’autre (nouveau -> ancien). Cela veut dire que vous ne devez pas utiliser le nouveau serveur en production, et encore moins basculer immédiatement en mettant le nouveau serveur dans vos fichiers de configuration. Toute insertion ou modification de vos données serait irrémédiablement perdue.

Typiquement, donc, vous lancerez une version de développement de votre application en remplaçant le nom d’hôte du serveur SQL par mysql2 ou postgresql2. Si vous avez une batterie de tests, lancez-la et vérifiez que tout fonctionne bien. Sinon, testez manuellement votre application pour vous assurer qu’elle fonctionne normalement.

La mise en production définitive du serveur se fera le lundi 19 octobre à partir de 2h (heure de Paris). L’opération totale devrait prendre environ 2h, mais nous essayerons de maintenir le serveur SQL en lecture seule durant le temps de la migration, pour limiter l’indisponibilité (un site en lecture seule étant souvent mieux qu’une page d’erreur).