En entornos de bases de datos con replicación, asegurar que la información en los nodos esclavos sea idéntica a la del nodo maestro es crítico. Percona Toolkit ofrece dos herramientas fundamentales para esta tarea: pt-table-checksum para la detección de divergencias y pt-table-sync para la resolución de las mismas de manera eficiente y segura.

Fundamentos de pt-table-checksum

Esta herramienta realiza una verificación en línea de la consistencia de los datos. Su ejecución se realiza en el nodo maestro, donde calcula sumas de comprobación (checksums) de los datos y las registra en una tabla específica. El mecanismo de replicación propaga estos cálculos a los esclavos, permitiendo comparar los resultados locales con los del maestro.

Para evitar bloqueos prolongados en tablas de gran volumen, la herramienta divide la información en bloques lógicos denominados chunks basados en índices únicos. Además, monitorea la carga del servidor y el retraso de la replicación (lag), pausando el processo si se superan los umbrales configurados.

Mecanismo de Sincronización con pt-table-sync

Mientras que la primera herramienta solo identifica errores, pt-table-sync se encarga de corregir las inconsistencias. Puede trabajar de forma autónoma o basarce en los resultados previos de un checksum. Su flujo de trabajo para reparar un bloque específico es el siguiente:

1. Bloquea el chunk en el maestro mediante un FOR UPDATE.
2. Obtiene la posición actual del log binario del maestro.
3. En el esclavo, ejecuta MASTER_POS_WAIT() para asegurar que la réplica haya alcanzado ese punto exacto.
4. Compara los checksums del bloque entre ambos nodos.
5. Si detecta diferencias, analiza fila por fila dentro del bloque y genera las sentencias REPLACE INTO o DELETE necesarias en el maestro para que el cambio se replique de forma natural al esclavo.

Configuración del Entorno

Antes de iniciar, es necesario instalar las dependencias de Perl requeridas en el sistema operativo (ejemplo basado en distribuciones tipo RedHat/CentOS):

yum install perl perl-devel perl-DBI perl-DBD-MySQL perl-Time-HiRes

Posteriormente, se debe preparar una base de datos de control y una tabla para almacenar los resultados del monitoreo. Aunque las herramientas pueden crear esto automáticamente con los permisos adecuados, se recomienda definir la estructura manualmente:

CREATE DATABASE IF NOT EXISTS db_monitor;

CREATE TABLE IF NOT EXISTS db_monitor.registro_checksum (
    base_datos  CHAR(64) NOT NULL,
    tabla       CHAR(64) NOT NULL,
    bloque      INT NOT NULL,
    tiempo_ejec FLOAT NULL,
    indice_usado VARCHAR(200) NULL,
    limite_inf  TEXT NULL,
    limite_sup  TEXT NULL,
    crc_local   CHAR(40) NOT NULL,
    cnt_local   INT NOT NULL,
    crc_maestro CHAR(40) NULL,
    cnt_maestro INT NULL,
    actualizado TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (base_datos, tabla, bloque),
    INDEX idx_ts (actualizado, base_datos, tabla)
) ENGINE=InnoDB;

Ejecución de la Verificación

Para iniciar el proceso de validación desde el maestro, se utiliza un comando similar al siguiente, ajustando los parámetros de conexión:

pt-table-checksum \
  --nocheck-binlog-format \
  --recursion-method=processlist \
  --replicate=db_monitor.registro_checksum \
  --databases=produccion_erp \
  --host=192.168.1.50 \
  --user=admin_db \
  --password='password_seguro'

Parámetros clave:

• --nocheck-binlog-format: Ignora la validación estricta del formato de binlog (útil si se usa formato ROW).
• --replicate: Especifica la tabla donde se guardarán los resultados.
• --recursion-method: Define cómo la herramienta encontrará a los esclavos conectados.

Detección de Inconsistencias

Una vez finalizado el proceso, se debe consultar la tabla de resultados en los esclavos para identificar dónde existen diferencias reales entre el conteo de filas o los valores hash:

SELECT base_datos, tabla, SUM(cnt_local) AS filas_totales, COUNT(*) AS bloques_analizados 
FROM db_monitor.registro_checksum 
WHERE (crc_maestro <> crc_local OR cnt_maestro <> cnt_local OR ISNULL(crc_maestro) <> ISNULL(crc_local))
GROUP BY base_datos, tabla;

Reparación de Datos

Para corregir los errores encontrados, se recomienda primero previsualizar los cambios antes de aplicarlos. Es vital ejecutar esto apuntando al esclavo afectado:

# Solo imprimir las sentencias de corrección
pt-table-sync --print --sync-to-master \
  h=192.168.1.51,u=admin_db,p='password_seguro' \
  --replicate=db_monitor.registro_checksum \
  --databases=produccion_erp

Si las sentencias SQL generadas son correctas, se puede proceder con la ejecución real añadiendo el parámetro --execute:

# Aplicar los cambios en el maestro para corregir el esclavo
pt-table-sync --execute --sync-to-master \
  h=192.168.1.51,u=admin_db,p='password_seguro' \
  --replicate=db_monitor.registro_checksum \
  --databases=produccion_erp

Consideraciones Técnicas Finales

• Índices: Ambas herramientas requieren que las tablas tengan una clave primaria o un índice único. Sin esto, pt-table-sync no podrá identificar filas específicas para su reparación.
• Carga del Sistema: Aunque estas herramientas son eficientes, en bases de datos con alta concurrencia se debe vigilar el parámetro --max-load para evitar degradar el rendimiento del servicio.
• Triggers y Constraints: El uso de REPLACE INTO para la sincronización puede disparar triggers en el maestro. Se debe evaluar el impacto en tablas con lógica compleja o restricciones de integridad referencial.
• Latencia de Red: pt-table-sync es sensible al lag. Si el esclavo tiene mucho retraso, el bloqueo en el maestro persistirá durante más tiempo, afectando la disponibilidad.