Toute architecture de base de données se doit de se reposer sur 3 piliers, la supervision (monitoring) , la sauvegarde/restauration et la haute disponibilité. Mon premier article de l'année 2018  concerne l'un des meilleurs combos du moment, en matière de haute disponibilité niveau base de données : - MySQL 5.7 Group Replication : la seule solution native HA de MySQL, qui permet notamment de faire du vrai multi-master (avec MySQL NDB Cluster mais ceci est hors sujet). - ProxySQL 1.4 : modestement le meilleur proxy pour MySQL.

C’était attendu depuis longtemps : MySQL 8.0 aura un optimiseur de requête amélioré et encore plus intelligent!  Les détails ici.

Un bref résumé des similarités et des différences des types TIMESTAMP et DATETIME sur MySQL.  Un court mais fort instructif article sur le sujet.

Testez-vous vos applications?  Vraiment?  Comme plusieurs, vous ne testez que pour voir si ça fonctionne bien, n’est-ce pas?  Mais comment votre application gère-t-elle les erreurs?

Comment votre application réagirait si votre serveur MySQL explosait en plein milieu d’une transaction?  Votre application pourrait-elle récupérer gracieusement de cette catastrophe sans encore plus aggraver le problème?

Vous me direz que créer de telles conditions de test n’est pas facile.  Alors, voici un excellent article sur quelques façons de faire crasher votre serveur MySQL!

Si vous développez sérieusement des applications/services qui ont à accéder à différentes version de MySQL, il existe un outil merveilleux pour ce faire: MySQL Sandbox.

Cet outil vous permet d’installer plusieurs versions de MySQL sur une même machine (sur Linux seulement) et ce, sans aucun conflit!

Pour une explication détaillée des variations dans le comportement des UPSERT dans MySQL, PostgreSQL, SQL Server et Oracle, il y a cet excellent article!

Si vous utilisez MySQL de façon intensive, le blogue de Jean-François Gagné est un incontournable!

Une page où vous pourrez avoir réponse à presque toutes vos questions concernant MySQL!

Pour ne nommer que deux améliorations dans MySQL 8.0, il y a les rôles (A quick tour of MySQL 8.0 roles) et des changements majeurs concernant les tablespaces (One Million Tables in MySQL 8.0).

Petite piqûre de rappel pour tous ceux qui se trouvent entre ces deux releases, la valeur du paramètre default_password_lifetime est fixée à 360 par défaut, ce qui signifie que si vous n’avez pas précisé la clause PASSWORD EXPIRE NEVER dans CREATE USER ou ALTER USER, le mot de passe expirera effectivement au bout de 360 jours, jolie bombe à retardement toutes topologies confondues (réplication 5.6->5.7). Y compris pour root@localhost:

mysql> select version() as 'Version', user, host, password_lifetime from mysql.user where user='root' ;
+----------+------+-----------+-------------------+
| Version  | user | host      | password_lifetime |
+----------+------+-----------+-------------------+
| 5.7.10-3 | root | localhost | NULL              |
+----------+------+-----------+-------------------+
1 row in set (0.00 sec)

Lorsque mysql.user.password_lifetime est à NULL, la valeur qui s’applique est celle du paramètre: …