Tengo un ZFS en un HDD con ZIL SLOG en un SSD.
Si eso es relevante, también tengo un caché LARC en un SSD.
¿Cómo puedo reconfigurarlo para estar seguro de que una falla de los SSD no causará inconsistencia en los datos (no conformidad con las reglas de resultados de llamadas del sistema de archivos POSIX, como mezclar el contenido de dos write()operaciones que vienen una tras otra en un solo hilo)?
Quiero asegurarme de que mi base de datos PosgreSQL en ZFS no se vuelva inconsistente si restauro una instantánea de respaldo del HDD sin restaurar los SSD. (Tomo medidas para sincronizar PostgreSQL de tal manera que (siempre que Postgre no tenga errores) el sistema de archivos POSIX correcto garantice que la base de datos no se vuelva inconsistente).
Respuesta1
Se supone que ZIL solo contiene escrituras no confirmadas en discos estables durante un período corto. Si tuviste un corte de energía y un fallo de SSD al mismo tiempo, esto podría ser un problema. Pero si el ssd falla mientras las cosas son normales, zfs simplemente debería pasar del equivalente de escritura raid al modo de escritura raid. El rendimiento puede disminuir, pero nada debería dañarse inmediatamente.
El objetivo de ZIL es escribir cambios rápidamente en el almacenamiento no volátil para que se pueda indicar rápidamente a la aplicación que continúe. Si la energía fallaba antes de que también se escribieran en el almacenamiento estable (disco), se copiarían de ZIL al almacenamiento estable la próxima vez que se montara el volumen zfs después del encendido.
El objetivo de una instantánea del sistema de archivos es que se obtiene una versión estable del sistema de archivos para copiar en la que no se está escribiendo activamente. Esto no tiene nada que ver con ZIL, ya que la instantánea no debería poder escribirse, por lo que ZIL no tendrá ninguna escritura pendiente.
Dicho esto, es posible que postgreSQL no esté contento con la restauración de una instantánea del sistema de archivos. A menos que también se le indique a postgreSQL que realice una instantánea o haga una pausa justo antes de la instantánea de ZFS, la instantánea de zfs podría contener algunas escrituras parciales de postgreSQL, lo que podría ser un problema. Es posible que desee hacer una pregunta por separado sobre cómo realizar una copia de seguridad adecuada de una base de datos PostgreSQL. (...a menos que alguien más quiera cubrir eso aquí.)
Respuesta2
Se puede considerar que el SLOG es independiente del conjunto de datos. Lo que eso significa es que una vez que los datos de su página se han vaciado en el disco, se puede tomar una instantánea del conjunto de datos y hacer una copia de seguridad, y la instantánea se puede restaurar (en el mismo grupo y/o en un grupo diferente), ya sea que tenga un registro. dispositivo o no.
Si tiene la intención de eliminar físicamente un dispositivo log(SLOG) o cache(L2ARC) de su grupo, por supuesto, primero debe eliminarlo lógicamente:
zpool remove [poolname] [logdevice|cachedevice]
(Ver man zpool-remove)
Si no elimina un SLOG correctamente, es posible que el grupo no se importe en el próximo reinicio. Recuperarse de esto puede ser bastante fácil (si todavía no hay datos no eliminados en el SLOG) o difícil/imposible sin aceptar cierta corrupción de sus datos. Hay una razón por la que a menudo se recomienda agregar dos dispositivos SLOG como un par reflejado, y es para evitar exactamente este problema, es decir, evitar tener un único punto de falla capaz de corromper su grupo.
Seguiría haciendo pg_dumpcopias de seguridad periódicas (en otro conjunto de datos con su propia instantánea y programa de copia de seguridad) porque creo que los volcados de texto son más confiables que los archivos binarios, especialmente si la instantánea binaria se realizó mientras el servidor postgresql todavía estaba ejecutándose (el servidorpuedeNo he escrito todo lo que hay en la memoria en el disco cuando se tomó la instantánea... pero apagar el servidor hará que escriba todo lo que necesita para reiniciarse en el mismo estado). También porque cuando se trata de datos importantes, cuantas más copias de seguridad, mejor.
Por cierto, hace años escribí un script de respaldo postgresql simple que descarga todo, luego las pg globales (roles, etc.), luego el esquema para cada base de datos y tabla, y luego los datos (como COPY... FROM) y luego los datos. nuevamente como inserciones de columnas. He estado usando variantes durante unos 20 años. Publiqué una versión en ServerFault en¿Cuál es la mejor manera de automatizar la copia de seguridad de las bases de datos PostgreSQL?allá por 2009.
Esa versión probablemente necesite algunos ajustes menores (especialmente en la DBS=( $($PSQL --list --tuples-only ...) )línea que obtiene la lista de bases de datos. Y si el directorio de respaldo es un conjunto de datos zfs con su propia programación de instantáneas, no necesitará los subdirectorios YMD ni el archivo find ... -mtime +30 ...para eliminar copias de seguridad antiguas. Además, no necesitará canalizar pg_dumpo pg_dumpallingresar gzip, solo use compresión en el conjunto de datos de la copia de seguridad.