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_limitlimiter 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\Get 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_days1, 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\Gsur 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».

RolandoMySQLDBA
la source

Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat .

Paul White 9

Suppression des journaux de bacs dans l'environnement de réplication

Réponses: