Eu tenho um ZFS em um HDD com ZIL SLOG em um SSD.
Se isso for relevante, também tenho um cache LARC em um SSD.
Como posso reconfigurá-lo para ter certeza de que uma falha nos SSDs não causará inconsistência de dados (não conformidade com regras de resultados de chamadas do sistema de arquivos POSIX, como misturar conteúdo de duas write()operações que vêm uma após a outra em um único thread)?
Quero garantir que meu banco de dados PosgreSQL no ZFS não se torne inconsistente se eu restaurar um instantâneo de backup do HDD sem restaurar os SSDs. (Eu tomo medidas para sincronizar o PostgreSQL de tal forma que (desde que o Postgre não tenha bugs) o sistema de arquivos correto do POSIX garanta que o banco de dados não se torne inconsistente.)
Responder1
Supõe-se que o ZIL contenha apenas gravações não confirmadas em discos estáveis por um curto período. Se você teve uma falha de energia e uma falha de SSD ao mesmo tempo, isso pode ser um problema. Mas se o SSD falhar enquanto as coisas estavam normais, o zfs deveria apenas fazer a transição do equivalente ao modo raid write back para o modo raid write through. O desempenho pode cair, mas nada deve ser corrompido imediatamente.
O objetivo do ZIL é gravar rapidamente as alterações no armazenamento não volátil para que o aplicativo possa ser informado rapidamente para continuar. Se a energia falhasse antes que eles também fossem gravados no armazenamento estável (disco), eles seriam copiados do ZIL para o armazenamento estável na próxima montagem do volume zfs após a inicialização.
O objetivo de um instantâneo do sistema de arquivos é que você obtenha uma versão estável do sistema de arquivos para copiar e que não esteja sendo gravada ativamente. Isso não tem nada a ver com o ZIL, pois o instantâneo não deve ser gravável, portanto o ZIL não terá nenhuma gravação pendente para ele.
Dito isto, o postgreSQL pode não ficar satisfeito com a restauração de um instantâneo do sistema de arquivos. A menos que o postgreSQL também seja instruído a fazer um snapshot ou pausar logo antes do snapshot do ZFS, o snapshot do zfs pode conter algumas gravações parciais do postgreSQL, o que pode ser um problema. Você pode fazer uma pergunta separada sobre como fazer backup adequado de um banco de dados postgreSQL. (...a menos que alguém queira abordar isso aqui.)
Responder2
O SLOG pode ser considerado independente do conjunto de dados. O que isso significa é que, depois que os dados do pg forem descarregados para o disco, o conjunto de dados poderá ser instantâneo e fazer backup, e o instantâneo poderá ser restaurado (para o mesmo pool e/ou para um pool diferente), independentemente de ter um log dispositivo ou não.
Se você pretende remover fisicamente um dispositivo log(SLOG) ou cache(L2ARC) do seu pool, você deve, é claro, removê-lo logicamente primeiro:
zpool remove [poolname] [logdevice|cachedevice]
(Ver man zpool-remove)
Se você não remover um SLOG corretamente, o pool poderá falhar na importação na próxima reinicialização. A recuperação disso pode ser bastante fácil (se ainda não houver dados não liberados no SLOG) ou difícil/impossível sem aceitar alguma corrupção de seus dados. Há uma razão pela qual é frequentemente recomendado adicionar dois dispositivos SLOG como um par espelhado, e isso é para evitar exatamente esse problema - ou seja, evitar ter um único ponto de falha capaz de corromper seu pool.
Eu ainda estaria fazendo pg_dumpbackups regulares (para outro conjunto de dados com seu próprio snapshot e agendamento de backup) porque acho que dumps de texto são mais confiáveis que binários - especialmente se o snapshot binário foi feito enquanto o servidor postgresql ainda estava em execução (o servidorpoderianão ter gravado tudo na memória no disco quando o instantâneo foi tirado... mas desligar o servidor fará com que ele grave tudo o que precisa para reiniciar no mesmo estado). Até porque quando se trata de dados importantes, mais backups são melhores.
A propósito, escrevi um script de backup postgresql simples anos atrás que despeja tudo, depois os pg globais (funções, etc), depois o esquema para cada banco de dados e tabela e, em seguida, os dados (como COPY ... FROM) e depois os dados novamente como inserções de coluna. Tenho usado variantes dele há cerca de 20 anos. Publiquei uma versão dele no ServerFault emQual é a melhor maneira de automatizar o backup de bancos de dados PostgreSQL?em 2009.
Essa versão provavelmente precisa de alguns pequenos ajustes (especialmente na DBS=( $($PSQL --list --tuples-only ...) )linha que obtém a lista de bancos de dados. E se o diretório de backup for um conjunto de dados zfs com sua própria programação de snapshot, você não precisará dos subdiretórios YMD ou do find ... -mtime +30 ...para excluir backups antigos. Além disso, você não precisará canalizar pg_dumpou pg_dumpallentrar gzip, apenas use a compactação no conjunto de dados de backup.