Étant donné que le temps de réplication MySQL est une variable incontrôlable (même dans des implémentations appropriées, des problèmes peuvent survenir qui bloquent la réplication ou la bloquent), il est préférable de ne pas compter sur la réplication des données. Vous pouvez décomposer le problème en deux situations :
1) Je suis l'utilisateur qui effectue une opération CUD, je m'attends à ce que la suite de l'opération R reflète la modification que je viens d'apporter. Dans ce cas, vous devez absolument extraire les données du maître, car l'utilisateur s'attend à ce que sa modification ait un effet.
2) Je suis un utilisateur extérieur, je ne sais pas qu'une commande CUD s'est produite et je m'en fiche généralement, donc le retour de données obsolètes est acceptable (dans 99% des implémentations, sinon vous n'utiliseriez probablement pas PHP * ).
Une alternative à #1 serait d'informer l'utilisateur que son changement se propage et est acceptable dans certaines situations, par ex. de nombreux sites Web vous diront que x peut prendre jusqu'à y minutes pour apparaître, c'est cette situation en action.
- Si vous avez besoin de mises à jour instantanées, vous pouvez essayer d'écrire dans une couche de cache qui est interrogée avec les données de base de données (potentiellement non fiables). Quelque chose comme memcached serait un candidat de choix.
