ex : beaucoup de lecture (large publique) et peu d'ecriture
tu fais ton CMS pour ecrire toujours sur 1 ou 2 noeuds,
puis tu utilises de la replication au niveau systeme de fichier pour les autres noeuds, qui ne seront alors qu'en lecture seule.
si tu dois avoir aussi beaucoup d'ecriture (phpBB avec un large public dans ton exemple) il faut regarder les mecanismes de replications fournis directement par la base de donnée et qui demandent parfois un peu de tuning sur les IDs des insertions par exemple
ex : noeud 1, insertion des IDs xxxxxx1
noeud 2, insertion des IDs yyyyy2
noeud 3, insertion des IDs zzzzz3
etc
bref, avant de reinventer la poudre,
bien lire les manuels des solutions pour comprendre que c'est deja prevu, et que cela a deja été testé
# ca depend de ton archi cible...
Posté par NeoX . En réponse au message [Discutions] Le clustering de base de données en 2017. Évalué à 3.
ex : beaucoup de lecture (large publique) et peu d'ecriture
tu fais ton CMS pour ecrire toujours sur 1 ou 2 noeuds,
puis tu utilises de la replication au niveau systeme de fichier pour les autres noeuds, qui ne seront alors qu'en lecture seule.
si tu dois avoir aussi beaucoup d'ecriture (phpBB avec un large public dans ton exemple) il faut regarder les mecanismes de replications fournis directement par la base de donnée et qui demandent parfois un peu de tuning sur les IDs des insertions par exemple
ex : noeud 1, insertion des IDs xxxxxx1
noeud 2, insertion des IDs yyyyy2
noeud 3, insertion des IDs zzzzz3
etc
bref, avant de reinventer la poudre,
bien lire les manuels des solutions pour comprendre que c'est deja prevu, et que cela a deja été testé