Tengo una pregunta sobre cómo eliminar registros binarios en el entorno de replicación:

Tenemos un entorno con 1 maestro y 2 esclavos (ejecutando mysql 5.5). A veces, nos encontramos con problemas de espacio durante tiempos de procesamiento pesados, por lo que el directorio bin log se llena. Los registros caducan cada 3 días. Me preguntaba, ¿hay alguna razón por la cual los registros se deben mantener durante 3 días en todas las cajas: maestro y ambos esclavos? ¿Tendría sentido, por ejemplo, mantener registros durante 3 días en un maestro, pero durante 1 día en esclavos? ¿Cuál es la mejor manera de hacerlo?

¡Gracias!

ESCLAVO

Si sus esclavos no son maestros, entonces los esclavos no necesitan registro binario en absoluto. Puede poner un límite a la cantidad de espacio de registro de retransmisión acumulado por un esclavo. Para acelerar los registros de relé a 4G, agregue relay_log_space_limita /etc/my/.cnf en cada esclavo

[mysqld]
relay_log_space_limit=4G

y reiniciar mysql

Si no puede configurar esto, al menos debería tener algún tipo de alerta SHOW SLAVE STATUS\Gy verificar el valor de Relay_Log_Space(bytes totales consumidos por los registros de retransmisión).

MAESTRO

En cuanto al Maestro, podrías establecerlo expire_logs_daysen 1, pero hay una advertencia severa que tengo para ti ...

Si se rompe la replicación, tiene 1 día para solucionarlo. De lo contrario, un registro binario en el maestro puede rotar y no puede ejecutar ningún comando CHANGE MASTER TO para realinear la replicación. Me iría expire_logs_daysa las 3 en el Master.

SUGERENCIA # 1

Si tiene que realizar un procesamiento masivo durante la noche, tal vez debería ejecutar los procesos masivos en el maestro con SET SQL_LOG_BIN=0;al inicio de la sesión. Esto, por supuesto, no se replicará al Esclavo. Puede realizar la misma carga masiva en paralelo a ambos esclavos.

SUGERENCIA # 2

Otra cosa que podría hacer para administrar la acumulación de registros binarios maestros es esto.

Corre SHOW SLAVE STATUS\Gcon ambos esclavos. Mira Relay_Master_Log_File. Eso representa el registro binario en el maestro cuyo último comando se ejecutó en el esclavo.

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

En este ejemplo, Relay_Master_Log_File es mysql-bin.009590. Todos los registros binarios anteriores a este se pueden eliminar de Master. Podrías ejecutar esto en el Master:

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

Esto borrará los registros más antiguos y aún dejará la réplica intacta.

CONSIDERACIÓN

Los registros binarios son archivos que compilan en serie (como una cola FIFO) todas las transacciones SQL completadas como una declaración SQL o un cambio de fila. Un registro de retransmisión es un archivo que recopila entradas de registro binario de un servidor remoto (también conocido como Maestro).

En replicación MySQL

1. El maestro debe tener sus registros binarios habilitados
2. Slave compila registros de retransmisión
3. Cuando se procesa todo el SQL en un registro de retransmisión, se elimina
4. En un Esclavo, cuando hay más de un registro de retransmisión en un Servidor DB, puede indicar que la replicación se está quedando atrás porque el subproceso IO está recopilando SQL de un Maestro más rápido de lo que el subproceso SQL puede procesar los registros de retransmisión.
5. El uso de relay_log_space_limit evita que la replicación se acumule y potencialmente llene un disco. Los registros de relé giran según la regla n. ° 3
6. Es posible que un servidor DB sea maestro y esclavo. Esa es la única circunstancia bajo la cual un Esclavo debe tener registros binarios habilitados. En ese escenario, un servidor DB tendrá registros binarios y registros de retransmisión.

Si conmutas por error a un esclavo y quieres convertirlo en un maestro

• servicio mysql stop
• Añadir log-bin=mysql-bina /etc/my.cnf en el esclavo
• servicio mysql start

Deberá configurar la replicación de otros esclavos para el maestro recién ascendido y asegurarse de que los datos del esclavo coincidan con el maestro recién ascendido

ACTUALIZACIÓN 2012-08-13 17:47 EDT

De acuerdo con la opción de documentación de MySQLrelay-log , debe definirla. Aquí es por qué:

Debido a la forma en que MySQL analiza las opciones del servidor, si especifica esta opción, debe proporcionar un valor; el nombre base predeterminado se usa solo si la opción no se especifica realmente. Si usa la opción --relay-log sin especificar un valor, es probable que se produzca un comportamiento inesperado; Este comportamiento depende de las otras opciones utilizadas, el orden en que se especifican y si se especifican en la línea de comandos o en un archivo de opciones. Para obtener más información acerca de cómo MySQL maneja las opciones del servidor, consulte la Sección 4.2.3, “Especificación de las opciones del programa”.