sont mises aux votes. La réplication étant très populaire, et les projets d'améliorations étant très nombreux, les auteurs de la réplication ont mis en place un vote pour établir des...
Voici les prochaines fonctionnalités que la réplication MySQL devra supporté, tel que recensé dans un sondage sur le futur de cette technologie :
Vérifications en ligne que le maître et l'esclave sont en ligne : 45.4%
Réplication muli-source: réplication depuis plusieurs maîtres vers un esclave: 36.3%
Application multi-threadées des données sur l'esclave pour améliorer les performances ; 29.2%
Résolution de conflit : détection précoce que les lignes ne sont pas répliquées
: 21.0%
Réplication semi-synchrone : les transactions sont copiées vers un esclave avant archivage : 20.3%
Après avoir optimisé votre serveur MySQL, si vous décidez d'activer la réplication, vous pouvez vous attendre à une baisse de performances. Pourquoi? Car la réplication requiert les logs binaires, qui...
Un problème courant de la réplication MySQL est le lag, ou encore le retard entre le serveur maître et les serveurs esclave. La réplication est asynchrone, et les deux peuvent finalement être séparé d'une durée variable.
Dries Buytaert propose plusieurs approches pour gérer ce retard, à défaut de le corriger.
1. Exécuter les requêtes sur le maître, sauf en lecture seule
2. Passer en réplication synchrone (cluster MySQL, patch Google)
3. Utiliser un équilibreur de charge, ou un proxy
4. Utiliser le partitionnement et le sharding
5. Réécrire l'application pour qu'elle gère ce retard
6. Utiliser le modèle media wiki, où on teste le retard, et on attend qu'il se résorbe
Ce tutorial décrit comment configurer une réplication MySQL de maître à maître. Nous devons assurer la réplication de serveur pour obtenir la haute disponibilité. Dans mon cas, j'ai besoin de...
Baron Schwartz vient de mesurer la vitesse de réplication de MySQL. À la milli-seconde, il a mesuré le temps que prend une architecture MySQL à faire passer les informations du maître à l'esclave. Cette opération n'est pas immédiate, puisqu'il faut que le maître note les requêtes dans le log binaire, que ce dernier soit envoyé à l'esclave, et que finalement, les requêtes soient aussi exécutées sur l'esclave.
Au final, Baron trouve que MySQL assure la réplication entre 200 et 300 millisecondes, ce qui est pas mal du tout. Cela donne aussi une idée des délais minimals de réplication que l'on peut attendre d'une architecture, puisque dans son test, le temps de réplication n'inclut aucun transfert réseau ni charge secondaire sur le serveur. How fast is MySQL replication? (0 visite)
La réplication MySQL maître à maître (souvent en mode actif-passif) est une solution populaire pour les compagnies qui veulent supporter des traffics croissants. La plupart d'entre elles réalisent des solutions...
La réplication MySQL est une technique pour multiplier la puissance d'un serveur : les données et les opérations sont répliquées, c'est à dire copiées vers des serveurs esclaves, qui agissent...
Giuseppe Maxia se fend d'un excellent article sur la réplication, avec 2 parties :
+ Comment organiser un système de réplication circulaire avec des colonnes auto_increment qui ne se marchent...
Le plus gros parasite de la réplication est le retard (replication lag) : c'est le fait que les esclaves soient en retard sur le maître. Pour certaines applications, ce n'est pas un gros problème, mais pour d'autres, comme celles qui utilisent la base de données pour stocker les sessions, c'est plus difficile à accepter.
Peter Zaitsev identifie les sources de retards sur une architecture de réplication : la charge de l'esclave (qui doit servir les lectures en plus de rattraper les écritures), les verrous (qui bloquent tous les requêtes, y compris le thread de réplication), les longues requêtes (qui ennuient tout le monde).
Au final, il est recommandé d'inclure dans l'application des systèmes qui s'adaptent à ce retard, plutôt que de faire planter l'application. Managing Slave Lag with MySQL Replication (0 visite)
La partie difficile dans une réplication est l'initialisation des données sur l'esclave. La récupération des données, qu'elle se fasse via le système ou bien directment en commande MySQL, impose un lourd travail d'exportation au maître.
Keith Murphy vous propose une astuce, pour ajouter un second esclave à un maître : utilisez le second esclave pour prendre les données ET le point de réplication. Une fois les données lues sur cet esclave, reportez le nouvel esclave sur le maître, avec le point de réplication obtenu de l'autre esclave.
Lisez le billet pour connaître toutes les commandes.
Comment est-ce possible? Un esclave avec plusieurs maîtres? En fait, le nom de cette architecture n'est pas exactement ce qu'elle implique. Nous allons créer un anneau de réplication entre les...
Il y a eu récemment une discussion comme sujet la mort de la réplication MySQL avec la participation de Brian Aker, puis Farhan, Arjen et Paul.
La prochaine génération de réplication approche et sera clairement à l'ordre du jour de l'industrie Les dirigeants et les adeptes pack. Nous devrions regarder et de se demander l'orientation de la programmation en se posant toutefois quelques questions. Tels que:
1. L'utilisation - Quel est / a été utilisée pour la réplication MySQL'
2. Les motifs - Pourquoi était-il utilisé?
3. Les problèmes - Pourquoi y at-il un besoin pour quelque chose de meilleur, différent ou amélioré?
Cependant vous pouvez obtenir les directions et orientations concernant cette futur réplication. Replication++, Replication 2.0, Replication. suite (0 visite)
Lors de la mise en place d'une réplication, il faut modifier son application PHP pour diriger les lectures sur les esclaves et les écritures sur le maître. On y arrive souvent en passant par une couche intermédiaire qui fait la distribution. Avec MySQL Proxy, cette couche peut se faire de manière transparante pour l'application.
Un script LUA sur MySQL Proxy va distribuer correctement les transactions et écritures vers le maître, et les autres requêtes vers les esclaves. MySQL Proxy est aussi capable de surveiller tout un pool d'esclaves, et de répartir les requêtes sur les esclaves qui fonctionnent (par opposition à ceux qui sont inaccessibles).
Lorsque la réplication retarde de 3 secondes, cela a un impact sur la cohérence d'un serveur Web. Mais alors, quel est le fou qui veut pouvoir configurer 30 minutes de retard sur une réplication?
En fait, la réplication permet de protéger un serveur contre les crash : si le serveur maître plante, l'esclave dispose déjà des commandes nécessaires pour proposer une sauvegarde de secours, jusqu'au moment du crash. Mais si c'est une erreur d'administration, où la commande DROP TABLE n'est pas munie d'une condition WHERE, alors votre bévue sera immédiatement répercutée sur l'esclave et donc, la sauvegarde. La réplication protège contre les crash, mais pas contre les bourdes.
La réplication retardée, de 30 minutes par défaut, peut vous aider dans ce genre de situations. Time delayed replication (0 visite) MySQL: Time Delayed Replication (0 visite)
