Tenho uma pergunta sobre a exclusão de logs binários no ambiente de replicação:

Temos um ambiente com 1 mestre e 2 escravos (executando o mysql 5.5). Às vezes, encontramos problemas de espaço durante tempos de processamento intensos, nos quais o diretório bin log fica cheio. Os logs expiram a cada 3 dias. Eu queria saber, existe uma razão pela qual os logs devem ser mantidos por 3 dias em todas as caixas - mestre e ambos os escravos? Faria sentido, por exemplo, manter registros por 3 dias em um mestre, mas por 1 dia em escravos? Qual é a melhor maneira de fazer isso?

Obrigado!

ESCRAVO

Se os seus escravos não são mestres, os escravos não precisam de log binário. Você pode limitar a quantidade de espaço do log de retransmissão acumulado por um escravo. Para acelerar os logs de retransmissão em 4G, adicione relay_log_space_limit/etc/my/.cnf em cada Escravo

[mysqld]
relay_log_space_limit=4G

e reinicie o mysql

Se você não pode definir isso, pelo menos deve ter algum tipo de alerta SHOW SLAVE STATUS\Ge verificar o valor de Relay_Log_Space(total de bytes consumidos pelos logs de retransmissão).

MESTRE

Quanto ao Mestre, você pode definir expire_logs_dayscomo 1, mas há um aviso severo que tenho para você ...

Se a replicação for interrompida, você terá 1 dia para corrigi-la. Caso contrário, um log binário no mestre poderá girar para longe e você não poderá executar nenhum comando CHANGE MASTER TO para realinhar a replicação. Eu sairia expire_logs_daysàs 3 no Mestre.

SUGESTÃO # 1

Se você tiver algum processamento em massa durante a noite, talvez deva executar os processos em massa no Master SET SQL_LOG_BIN=0;no início da sessão. Obviamente, isso não será replicado para o Escravo. Você pode executar a mesma carga em massa em paralelo aos dois escravos.

SUGESTÃO # 2

Outra coisa que você pode fazer para gerenciar a acumulação de logs binários principais é isso.

Corra SHOW SLAVE STATUS\Gem ambos os escravos. Olhe para Relay_Master_Log_File. Isso representa o log binário no mestre cujo último comando foi executado no escravo.

*************************** 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)

Neste exemplo, Relay_Master_Log_File é mysql-bin.009590. Todos os logs binários anteriores a este podem ser removidos do Master. Você pode executar isso no Master:

PURGE BINARY LOGS TO 'mysql-bin.009590';

Isso apagará os logs mais antigos e ainda deixará a replicação intacta.

EMBARGO

Logs binários são arquivos que compilam serialmente (como uma fila FIFO) todas as transações SQL concluídas como uma instrução SQL ou uma alteração de linha. Um log de retransmissão é um arquivo que coleta entradas de log binárias de um servidor remoto (também conhecido como Mestre).

Na replicação do MySQL

1. O mestre deve ter seus logs binários ativados
2. Escravo compila logs de retransmissão
3. Quando todo o SQL em um log de retransmissão é processado, ele é excluído
4. Em um Escravo, quando houver mais de um log de retransmissão em um servidor de banco de dados, isso pode indicar que a replicação está atrasada porque o encadeamento IO está coletando SQL de um mestre mais rapidamente que o encadeamento SQL pode processar os logs de retransmissão.
5. O uso de relay_log_space_limit impede que a replicação se acumule e potencialmente encha um disco. Os logs de retransmissão são rotacionados com base na regra nº 3
6. É possível que um servidor de banco de dados seja mestre e escravo. Essa é a única circunstância sob a qual um escravo deve ter logs binários ativados. Nesse cenário, um servidor de banco de dados terá logs binários e logs de retransmissão.

Se você fizer failover para um escravo e quiser torná-lo um mestre

• serviço mysql stop
• Adicione log-bin=mysql-binao /etc/my.cnf no Slave
• serviço mysql start

Você precisará configurar a replicação de outros escravos para o mestre recém-promovido e garantir que os dados no escravo correspondam ao mestre recém-promovido

ATUALIZAÇÃO 13-08-2012 17:47 EDT

De acordo com a opção Documentaçãorelay-log do MySQL , você deve defini-la. Aqui está o porquê:

Devido à maneira como o MySQL analisa as opções do servidor, se você especificar esta opção, deverá fornecer um valor; o nome de base padrão será usado apenas se a opção não estiver realmente especificada. Se você usar a opção --relay-log sem especificar um valor, é provável que ocorra um comportamento inesperado; esse comportamento depende das outras opções usadas, da ordem em que são especificadas e se são especificadas na linha de comandos ou em um arquivo de opções. Para obter mais informações sobre como o MySQL lida com opções de servidor, consulte a Seção 4.2.3, “Especificando opções de programa”.