ESCLAVE
Si vos esclaves ne sont pas des maîtres, les esclaves n'ont pas du tout besoin de journalisation binaire. Vous pouvez limiter la quantité d'espace de journal de relais accumulée par un esclave. Pour relay_log_space_limit
limiter les journaux de relais en 4G, ajoutez à /etc/my/.cnf sur chaque esclave
[mysqld]
relay_log_space_limit=4G
et redémarrez mysql
Si vous ne pouvez pas définir cela, au moins vous devriez avoir une sorte d'alerte qui le fait SHOW SLAVE STATUS\G
et vérifier la valeur de Relay_Log_Space
(nombre total d'octets consommés par les journaux de relais).
MAÎTRE
Quant au Maître, vous pouvez définir expire_logs_days
1, mais il y a un avertissement sévère que j'ai pour vous ...
Si la réplication échoue, vous avez 1 jour pour le réparer. Sinon, un journal binaire sur le maître peut pivoter et vous ne pouvez pas exécuter de commande CHANGE MASTER TO pour réaligner la réplication. Je partirais expire_logs_days
à 3 heures du Master.
SUGGESTION # 1
Si vous avez un traitement en bloc du jour au lendemain, vous devriez peut-être exécuter les processus en bloc sur le maître SET SQL_LOG_BIN=0;
au début de la session. Bien sûr, cela ne se reproduira pas sur l'esclave. Vous pouvez effectuer la même charge en bloc en parallèle aux deux esclaves.
SUGGESTION # 2
Une autre chose que vous pourriez faire pour gérer l'accumulation de journaux binaires principaux est la suivante.
Exécutez SHOW SLAVE STATUS\G
sur les deux esclaves. Regardez Relay_Master_Log_File
. Cela représente le journal binaire sur le maître dont la dernière commande a été exécutée sur l'esclave.
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.4.92.250
Master_User: replicant
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.009677
Read_Master_Log_Pos: 855227755
Relay_Log_File: relay-bin.000674
Relay_Log_Pos: 757296783
Relay_Master_Log_File: mysql-bin.009590
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 757296646
Relay_Log_Space: 94274010765
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 80561
1 row in set (0.00 sec)
Dans cet exemple, Relay_Master_Log_File est mysql-bin.009590. Tous les journaux binaires avant celui-ci peuvent être supprimés de Master. Vous pouvez exécuter ceci sur le Master:
PURGE BINARY LOGS TO 'mysql-bin.009590';
Cela effacera les journaux plus anciens et laissera la réplication intacte.
CAVEAT
Les journaux binaires sont des fichiers qui compilent en série (comme une file d'attente FIFO) toutes les transactions SQL terminées sous la forme d'une instruction SQL ou d'un changement de ligne. Un journal de relais est un fichier qui recueille des entrées de journal binaire à partir d'un serveur distant (alias Maître).
Dans la réplication MySQL
- Le maître doit avoir ses journaux binaires activés
- L'esclave compile les journaux de relais
- Lorsque tout le SQL dans un journal de relais est traité, il est supprimé
- Sur un esclave, lorsqu'il y a plus d'un journal de relais sur un serveur de base de données, cela peut indiquer que la réplication est en retard car le thread IO collecte le SQL d'un maître plus rapidement que le thread SQL peut traiter les journaux de relais.
- L'utilisation de relay_log_space_limit empêche la réplication d'empiler et potentiellement de remplir un disque. Les journaux de relais tournent en fonction de la règle # 3
- Il est possible qu'un serveur DB soit à la fois maître et esclave. C'est la seule circonstance dans laquelle un esclave doit avoir activé les journaux binaires. Dans ce scénario, un serveur DB aura à la fois des journaux binaires et des journaux de relais.
Si vous basculez vers un esclave et que vous souhaitez en faire un maître
- service mysql stop
- Ajouter
log-bin=mysql-bin
à /etc/my.cnf sur l'esclave
- service mysql start
Vous devrez configurer la réplication d'autres esclaves vers le maître nouvellement promu et vous assurer que les données sur l'esclave correspondent au maître nouvellement promu.
MISE À JOUR 2012-08-13 17:47 EDT
Selon l' option MySQL Documentation onrelay-log
, vous devez la définir. Voici pourquoi:
En raison de la manière dont MySQL analyse les options du serveur, si vous spécifiez cette option, vous devez fournir une valeur; le nom de base par défaut n'est utilisé que si l'option n'est pas réellement spécifiée. Si vous utilisez l'option --relay-log sans spécifier de valeur, un comportement inattendu est susceptible de se produire; ce comportement dépend des autres options utilisées, de l'ordre dans lequel elles sont spécifiées et de leur spécification sur la ligne de commande ou dans un fichier d'options. Pour plus d'informations sur la façon dont MySQL gère les options du serveur, reportez-vous à la Section 4.2.3, «Spécification des options de programme».