web-dev-qa-db-fra.com

MySQL Replication - Mise à jour de l'esclave

J'ai une configuration maître-esclave de MySQL. Si je fais des modifications dans la base de données des esclaves ...

  1. Est-ce que ça va gâcher la synchronisation de quelque manière que ce soit?
  2. Les changements seront-ils remplacés du maître lors de la prochaine épreuve de réplication?
  3. Puis-je faire ci-dessus (2) l'option se produire?
mysqlmysqladmin
5
user1249065

Les réponses à vos questions sont ci-dessous:

1) va-t-il gâcher la synchronisation de quelque manière que ce soit

Réponse: Oui, il gâchera votre processus de réplication comme esclave se lit à partir du journal des relais et des mises à jour sur le serveur. Par exemple: Si une ligne a été ajoutée à esclave et qui n'est pas là en Master, la requête "Insert dans ..." échouera, ce qui peut causer l'arrêt du processus de réplication.

2) Les modifications seront-elles écrasées à partir du maître lors de l'événement de réplication suivant, puis-je prendre ci-dessus (2) l'option se produire?

Réponse: Non. Mais il y a une alternative que vous pouvez utiliser PT-TABLE-SYNC Outil

Cet outil change de données, donc pour une sécurité maximale, vous devez sauvegarder vos données avant de l'utiliser. Lors de la synchronisation d'un serveur qui est un esclave de réplication avec les méthodes - replicat ou -sync-to-maître, il apporte toujours les modifications sur le maître de réplication, jamais la réplication esclave directement. Ceci est en général le seul moyen sûr d'apporter une réplique en Sync avec son maître;

Remarque: Il est judicieux de définir des esclaves comme read_only Cette variable peut aider à prévenir certaines écrivies peu sûres de se produire sur des esclaves, Mais uniquement si les utilisateurs ne sont pas inutilement accordés au Super Privilege.

1
Peter Venderberghe

Veuillez trouver les réponses inline ci-dessous.

1. Est-ce que cela gâchera la synchronisation de quelque manière que ce soit -

Sur une vue architecturale de haute disponibilité "oui". Autant que vous ayez un maître et que vous soyez stables, vous ne pouvez pas finir de problèmes.

2. Les modifications seront-elles remplacées du maître lors de la prochaine réplication

Depends upon your changes.

En maître

create table test (id int, name varchar(20));
insert into test values (12,'Mannoj');

-------------------------
|id  | name             |
-------------------------
|12  | Mannoj           |
-------------------------

Les mêmes données et la même structure que vous pouvez voir dans esclave également.

Maintenant sur esclave faire une mise à jour comme

update table test set name='Villain' where id=12;

À ce moment-là, le Master tente de mettre à jour comme ça.

update table test set id=14 where  name='Mannoj';

Maintenant, la synchronisation est cassée sur l'esclave. Votre sql_slave_thread cesse.

Ou encore des déclarations contradictoires tente d'annoncer qu'il sera cassé, ci-dessus en est un meilleur exemple pour cela.

Mais si vous obtenez des mises à jour comme ci-dessous sur Master, assurez-vous que vos données esclaves sont cohérentes avec Master.

update table test set name='Hero' where id=12;

Pour cela, vous devez être si sûr de votre architecture d'application, de mieux vérifier avec l'équipe d'applications. Vous pouvez probablement vérifier leur code aussi.

. Puis-je faire ci-dessus (2) l'option se produire?

Oui, vous pouvez surmonter cela, à condition que vous devriez rencontrer des points ci-dessous.

  • Sans temps d'arrêt sur ha

    • Avoir un autre nouveau serveur esclave (S2) de la sauvegarde actuelle de l'esclave (S1). Pointez les deux esclaves à un maître (m). Faites vos affaires sur S2, même si cela se bloque que vous êtes le moins dérangé. (OU ALORS)

  • Avec le temps d'arrêt sur ha

    Pour ce faire, vous devez connaître votre application dans et dehors. Supposons que votre application effectue uniquement les DML des dernières données, telles que quelques secondes uniquement et non des données anciennes, alors ci-dessous l'aide.

    • Gardez l'esclave log_slave_updates activé sur l'esclave.
    • Maintenant émettre STOP SLAVE SQL_THREAD;Insight -> Mais io_slave_thread garde son espace ajouté sur relais_log que nécessaire pour être appliqué. Ce journal de relais sera purgé uniquement lorsqu'ils sont exécutés par fil SQL jusqu'à ce que vous ayez une purge automatique activée sur les journaux relais et le journal binaire de la maîtrise. Par ceci, vous avez des informations de Master Site sur Site Slave de quelles sont les transactions.
    • Après cela, vous pouvez faire des changements avec esclave.
    • Une fois les modifications sur esclave terminées, vous pouvez suivre le journal binaire de l'esclave et vérifier la valeur correspondante de chaque DML en maître avec les données en direct actuelles et modifier également les valeurs de l'esclave.
    • Maintenant, vous pouvez émettre START SLAVE SQL_THREAD; Bien sûr, il jette une erreur sous Last_Error: and Seconds_Behind_Master: NULL
    • Maintenant SET GLOBAL sql_slave_skip_counter = 1 et START SLAVE SQL_THREAD; -> jusqu'à ce que vous obteniez ceci Seconds_Behind_Master: 0
1
Mannoj

À moins que vous utilisiez le cluster MySQL, la réplication est strictement une opération à sens unique. Vous devriez non faire des modifications sur la copie esclave.

Quant à ce qui va se passer si vous le faites, il est difficile de dire que je n'ai jamais été assez stupide pour essayer :-)

Je soupçonne que cela fera le logiciel lorsque vous cassez le contrat - quel que soit ce que cela sait bien.

Mon conseil est de ne pas penser à la moindre possibilité de la pensée de cette action qui traverse votre esprit (paraphrasé de Douglas Adams HHGTTG).

0
paxdiablo

D'abord, je suis totalement d'accord que vous devriez éviter de le faire, sauf si des situations extrêmes, telles que les accidents du serveur maître et que chaque esclave a un statut différent pour rattraper avant de promouvoir un esclave d'être nouveau maître.

Si vous devez le faire, je pense qu'il est important de comprendre le mécanisme de la réplication MySQL (ou "synchronisation") en premier.

Sur le côté du serveur maître, chaque fois qu'un changement se produit, il n'envoie que le journal binaire correspondant aux esclaves, qui contient des requêtes SQL en format binaire.

Sur le côté serveur des esclaves, il utilise un thread IO et continue d'attendre l'événement du maître. Lorsqu'un nouvel événement se produit, l'esclave enregistre le journal binaire dans son propre journal de relais et un autre thread SQL commence à exécuter le contenu dans le journal du relais. Une fois que tout le contenu est exécuté dans le journal de relais actuel, il serait supprimé automatiquement par défaut (sauf si vous définissez le relais_log_purge = 0 manuellement).

Donc, pour le rendre simple, le processus de réplication ou de synchronisation n'est que 2 étapes: premiers transférer les mêmes requêtes SQL qui vient de se produire sur le maître à ses esclaves, seconde chaque esclave exécutez les requêtes SQL reçues.

Maintenant, je pense que c'est assez simple que se passerait dans votre cas:

  1. Cela dépend des changements que vous faites. Par exemple, si vous avez inséré/mis à jour une valeur de clé principale sur l'esclave manuellement et sur le maître de la même valeur est définie, il réussira le maître mais échouera sur l'esclave. Vous pouvez voir l'erreur MSG en utilisant "Afficher le statut esclave" sur l'esclave.

  2. Il est totalement possible si l'événement écrasante (je veux dire SQL), après votre changement manuel sur l'esclave, est émis sur Master. Et aussi aucun conflit ne se produit comme l'exemple ci-dessus.

  3. Vous avez la réponse que je suppose.

0
Brilliun