J'ai une question sur la suppression des journaux binaires dans l'environnement de réplication:
Nous avons un environnement avec 1 maître et 2 esclaves (exécutant mysql 5.5). Parfois, nous rencontrons des problèmes d'espace pendant les temps de traitement lourds, où le répertoire du journal de bin est plein. Les journaux expirent tous les 3 jours. Je me demandais, y a-t-il une raison pour laquelle les journaux devraient être conservés pendant 3 jours sur toutes les boîtes - maître et les deux esclaves? Serait-il sensé, par exemple, de conserver des journaux pendant 3 jours sur un maître, mais pendant 1 jour sur des esclaves? Quelle est la meilleure façon de procéder?
Je vous remercie!
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 limiter les journaux de relais en 4G, ajoutez relay_log_space_limit
vers /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 ne SHOW SLAVE STATUS\G
et vérifiez la valeur de Relay_Log_Space
(total d'octets consommés par les journaux de relais).
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 se casse, 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 laisserais (expire_logs_days
à 3 sur le maître.
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 avec 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.
Une autre chose que vous pourriez faire pour gérer l'accumulation de journaux binaires principaux est la suivante.
Courir SHOW SLAVE STATUS\G
sur les deux esclaves. Regarder 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 maître:
PURGE BINARY LOGS TO 'mysql-bin.009590';
Cela effacera les journaux plus anciens et laissera la réplication intacte.
Les journaux binaires sont des fichiers qui se 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'une modification de ligne. Un journal relais est un fichier qui recueille les entrées du journal binaire à distance serveur (alias Maître).
Dans la réplication MySQL
Si vous basculez vers un esclave et que vous souhaitez en faire un maître
log-bin=mysql-bin
à /etc/my.cnf sur l'esclaveVous 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.
Selon la documentation MySQL sur relay-log
option , 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".