optimizar la salida mysqldump para zfs dedup

Mi desafío es almacenar tantos volcados de mysql como sea posible en un grupo de ZFS dado.

La piscina en sí tiene dedup y compresión habilitados . Para almacenar múltiples versiones de los volcados se utilizan instantáneas (cada 15 minutos, cada hora, cada día, cada semana y cada mes).

La mayoría de las tablas en las diferentes bases de datos en el servidor MySQL están creciendo y no cambian muy a menudo. Mi pensamiento fue hacer un volcado por tabla en lugar de por base de datos para dar a zfs la oportunidad de realizar una dedicación a nivel de bloque.

El script de copia de seguridad usa la salida de mysqldump y la canaliza a un archivo (con mysqldmup -u$user -p$pass $db $table > $outputfile.sql

• ¿Es posible que ZFS dedup deduzca un flujo de la salida estándar a una buena tasa?
• ¿Debe configurarse manualmente el tamaño de bloque del datased de destino? (y en caso afirmativo, ¿de qué tamaño?)
• ¿Debería aplicarse algún tipo de búfer de salida (aparte del búfer de línea)?
• ¿Son las escrituras de una sincronización de redirección o asíncronas?

EDITAR para concretarlo: ¿Qué es necesario para hacer un archivo escrito línea por línea, como un archivo que se copió si el contenido (casi [por ejemplo, solo la última línea difiere]) es el mismo?

La deduplicación siempre está en el nivel de bloque (al igual que las instantáneas y la copia), la estructura de los datos anteriores no importa. Por lo tanto, podría tener un solo archivo en lugar de miles de archivos pequeños y no haría una diferencia en lo que respecta a la deduplicación.

Por otro lado, su tamaño de bloque sí hace una diferencia, debido a varias razones:

• Cuanto más grandes sean los bloques, más desperdicio se puede producir porque algunos bytes de un archivo muy pequeño pueden reservar el tamaño de un bloque grande (su tamaño de bloque es la unidad más pequeña y no se puede dividir más)
• Cuanto más pequeños sean sus bloques, más lento será su rendimiento en promedio, porque para leer el mismo archivo, ahora tiene que leer muchos más bloques (cada lectura tiene una ligera sobrecarga y cada bloque puede estar en una posición completamente diferente). todo el disco)
• La deduplicación funciona en bloques, por lo que un tamaño pequeño posiblemente obtenga mejores resultados
• Por otro lado, esto aumenta la cantidad de bloques a los que se hace referencia en la memoria y puede degradar su rendimiento. Para los cálculos de compensación y ejemplo, ver esta entrada de blog - Lo esencial es que necesita una gran cantidad de memoria y que depende de sus datos.

El tamaño es por lo tanto importante, pero también no tan fácil . Parece que ya tienes suficientes datos, así que solo lo probaría: crea dos sistemas de archivos (si es posible después y no simultáneamente para minimizar el efecto entre ellos), uno con un tamaño de bloque muy pequeño (4K), uno con un tamaño muy grande (128K) y luego copie sus datos y compare los resultados. También puede simular el rendimiento de deduplicación con zdb -b poolname comparando ambos recuentos de bloques y luego calculando sus ahorros. Si ninguno de esos resultados te parece bien, prueba diferentes tamaños como 16K, 32K o 64K.