Architecture MySQL en réplication

Bonjour à tous,

Tout d'abord, merci à ceux qui prendront du temps à me lire et à répondre à mes interrogations.

Je ne sais pas si cette partie est la plus adaptée, mais c'est ce qu'il me semblait.

Voici ce qui m'amène.


Je suis en train de concevoir un site pour améliorer mes connaissances en PHP/MySQL et je me fixe donc certains défis et innovations (pour moi) sur certaines choses.

Celle sur laquelle je bute actuellement est la meilleure manière de gérer différentes bases de données MySQL situées sur différents serveurs.

J'aimerais savoir quelle serait la meilleure facon de fonctionner sachant que j'ai un serveur principal (portail) et plusieurs serveurs secondaires.

J'avais donc pensé à mettre mes bases de données en réplication sur une seule table (users) qui est commune au portail et aux serveurs secondaires.

Seulement voilà, j'ai du mal à trouver le fonctionnement exact de la réplication couplée à PHP et donc si ce que je veux faire fonctionne avec MySQL.

Ce que j'aimerais faire est la chose suivante:

- Les utilisateurs créent leurs comptes sur le portail
- Ces comptes (table 'users') sont répliqués sur les serveurs secondaires
- L'administration par l'utilisateur de son compte se font sur les serveurs secondaires (changement de mot de passe, modification du profil, ... table 'users' toujours)
- Tous les serveurs doivent être à jour au niveau de ces modifications.

Je me demandais donc si le couple PHP/MySQL supporterait ce genre de fonctionnement avec la réplication et à quoi cela ressemblerait.

J'ai lu que MySQL supportait la réplication de certaines tables uniquement. Est-ce bien le cas?

Si un utilisateur change une information de son compte sur un serveur secondaire (Slave), où la requète va-t-elle aller? Envoyée directement au portail (master)? Si oui, que se passerait-il si le portail était offline? Est-ce mis en attente? Est-ce que la modification serait impossible?

Et là ca concerne un peu plus PHP, mais concrètement, qu'est-ce que des bases de données MySQL en réplication vont changer à la manière dont je manipulais ma base de données? Des commandes spécifiques pour les insert ou les update? MySQL gère-t-il cela tout seul et c'est transparent?


Voilà.

Je cherche donc des personnes capables de répondrent correctement à ces quelques questionnement profond sur la réplication MySQL et ses possibilités.

[Résumé]: Mon but étant donc de faire un portail qui crée les comptes, qui soit Master des serveurs secondaires; qu'il partage uniquement la table 'users' de sa base de données; et que les serveurs secondaires fassent les requètes pour les modifications des données du compte.


J'espère avoir été assez explicite, sinon j'essayerai de l'être + la prochaine fois.


Merci d'avance à tout ceux qui se pencheront sur mon topic!

Bonjour,

La réplication avec MySQL ne supporte sensément uniquement la réplication unidirectionnelle. Je cite une Q/R de MySQL :

Citation:

---

Q : Quels sont vos conseils concernant la réplication bi-bidirectionnelle?

R : La réplication MySQL ne supporte aucun protocole de verrouillage entre le maître et l'esclave pour garantir l'atomicité d'une modification entre les serveurs. En d'autres termes, il est possible pour un client A de faire une modification sur le serveur 1 et que dans le même temps, avant que cela ne se soit propagé au serveur 2, un client B se connecte au serveur 2, et fasse une modification sur le serveur 2 qui ne débouchera pas sur le même état que celui dans lequel le serveur 1 est. C'est ainsi qu'il ne faut pas lier de cette fa¸on deux serveurs, à moins que les modifications ne puisse se faire dans n'importe quel ordre, ou que vous sachiez prendre en charge des modifications anarchiques.

Vous devez aussi réaliser que la réplication bi-directionnelle n'améliore pas beaucoup les performances, tout au moins au niveau des modifications. Les deux serveurs doivent faire la même quantité de modifications, ainsi qu'un serveur seul le ferait. La seule différence est qu'il va y avoir moins de verrous, car les modifications qui proviennent d'un autre serveur seront optimisé par l'esclave. Cet avantage peut aussi être annulé par les délais réseau.

---

Le mieux reste donc de se contenter d'une réplication unidirectionelle.
Concernant sa mise en place elle consiste à :

• Avoir un serveur maître.
• Avoir une multitude de serveurs esclaves.

Statistiquement dans une utilisation courante de MySQL, plus de 90% des requêtes sont des interrogations (utilisation de la clause SELECT).
Le but de la réplication est de répartir la charge de ces 90% sur plusieurs serveurs au contenu identique. Pour ce faire nous devons nous interdir la lecture sur le serveur maitre puisqu'il sera dédié à l'écriture et la modification de données, puis d'effectuer les lectures réparties uniquement sur les esclaves (avec du load balancing par exemple) . Il n'est donc pas question de modifier les données sur un serveur esclave. La réplication peut être une bonne solution à ton problème, mais tout dépend du service que tu désire mettre en place.

Si tu veux pouvoir écrire des données sur plusieurs serveurs, je te conseille plutôt de te tourner vers le clustering. :king:

J'avais déjà lu ceci, d'où ma question sur le fonctionnement quand une requête de modification était demandée par un eslave.. Où va cette requête? Peut on la diriger immédiatement vers le maître?

Pour la réplication dont j'aurais besoin, elle ne sert pas vraiment à répartir la charge sur plusieurs serveurs.

Le portail (Master) n'a pas une monstrueuse gourmandise en select et autres. Il ne sert qu'à rediriger vers les serveurs secondaires (Slave).

Pour être plus précis. Le portail est celui d'un jeu PHP/SQL, les serveurs secondaires sont les univers de ce jeu. Le portail servant donc uniquement à créer un compte, faire les manipulations pour activer/récupérer celui-ci.

Mon soucis premier qui m'amène vers ce type de fonctionnement, c'est que j'aimerais permettre à un utilisateur d'avoir un seul et même compte pour tous les univers présents et futurs. Que les modifications qu'il ferait sur son compte au niveau des informations du compte lui-même (son profil, pas les données propre au compte par univers) soient synchronisées sur tous les univers.


J'ai continué à lire un petit peu ce que je trouvais sur la réplication MySQL cette après-midi. Je me dis qu'au final, il sera plus simple (mais moins esthétique) de travailler directement par des requêtes à travers le réseau et de configurer les serveurs pour ne s'autoriser qu'entre eux sur les ports MySQL.

A la limite, créer un seul énorme serveur MySQL contenant toutes les DB. Mais là on parle de cluster. Ca coûte très cher et je n'ai aucune idée de l'efficacité de ceux-ci pour un serveur MySQL.

Etant donné que c'est un jeu PHP très dynamique, j'utilise toutes les commandes de MySQL et pas seulement du SELECT.

Un gros doute donc pour savoir comment baser l'architecture MySQL pour ce type de site. Beaucoup de questions sur les performances d'un cluster MySQL ou une solution de requêtes à travers le réseau...

Une idée ou une possibilitée de m'aider vers où m'orienter?

La question est : la charge est elle suffisamment importante au point de décider d'utiliser trois serveurs ?
Quoi qu'il en soit d'après ta description, la réplication n'est peut-être pas la meilleure solution.
Si la charge est réellement trop importante, pourquoi ne pas centraliser les authentifications sur un seul serveur ?
Une fois authentifié, tu permet de gérer avec l'un ou l'autre serveur en fonction de l'univers de jeux de ton joueur.

Encore une fois, la réplication et le clustering sont des réponses à une charge trop importante, et non pas un moyen de concevoir une base de donnée (au contraire ça complique bien les choses).

Comme je l'ai expliqué dans le premier post, je cherche à apprendre de nouvelles choses principalement. Je me lance donc un défi.

Je travaille pour une société qui développe ce type de jeu et je me fais un petit projet sur mon temps libre en prenant comme base un nouveau jeu basé sur une nouvelle facon de gérer l'inscription.

Un de nos jeux fonctionne actuellement sur le principe d'un serveur par univers. Le portail a son propre serveur et ne sert qu'à rediriger. Les auth et la base de données des joueurs se situe directement sur chaque serveur d'univers.

Il est donc possible à chaque joueur d'avoir un login différent par univers et l'oblige à se créer un compte sur chaque univers et le refaire sur chaque nouvel univers. Ce qui provoque ainsi une difficulté à savoir quel joueur utilise quel compte sur un univers.

Mon but est donc d'apprendre une nouvelle facon de faire en permettant aux joueurs de ne se créer qu'un seul et unique compte qui fonctionne pour tous les univers, présents et futurs, ainsi que la création automatique de leur compte sur le forum. Ceci étant plus simple pour le joueur, pour l'équipe de support du jeu, même si bien plus compliqué pour concevoir le jeu.

J'étais donc partit sur l'idée d'un énorme cluster MySQL dans un premier temps avant de voir que MySQL permettait aussi la réplication.


Je vais donc me pencher sur l'authentification sur un seul serveur, comme vous le proposez.

Merci pour vos réponses :)