Usando o nó principal do ZFS como servidor de banco de dados?

Estou usando um NAS de cabeça dupla suportado por ZFS para armazenamento compartilhado em cluster de alta disponibilidade, com base na arquitetura recomendada da Nexenta, como mostrado aqui:

Os discos em 1 JBOD armazenam os arquivos de banco de dados para um único banco de dados Postgres de 4 TB e os discos no outro JBOD armazenam 20 TB de grandes arquivos simples binários brutos (resultados de cluster para grandes simulações de colisão de objetos estelares). Em outras palavras, o JBOD que faz backup dos arquivos do Postgres manipula principalmente cargas de trabalho aleatórias, enquanto o JBOD que faz backup dos resultados da simulação manipula principalmente as cargas de trabalho seriais. Ambos os nós principais têm 256 GB de memória e 16 núcleos. O cluster possui cerca de 200 núcleos cada, mantendo uma sessão do Postgres, portanto, espero cerca de 200 sessões simultâneas.

Gostaria de saber se é sensato, em minha instalação, fazer com que os nós principais do ZFS atuem simultaneamente como um par espelhado de servidores de banco de dados Postgres para o meu cluster? Os únicos inconvenientes que posso ver são:

Menos flexibilidade para dimensionar minha infraestrutura.
Nível de redundância ligeiramente mais baixo.
Recursos limitados de memória e CPU para o Postgres.

No entanto, a vantagem que vejo é que o ZFS é bastante idiota em relação ao failover automático e não preciso gastar muito trabalho para fazer com que cada servidor de banco de dados do Postgres descubra se um nó principal falhou, pois falhará com o cabeçalho nó.

— elleciel
fonte

O PostgreSQL não pode ser executado em nenhuma forma de modo de armazenamento compartilhado. As tentativas de fazer isso falharão. Tentativas de ignorar as proteções para impedi-lo de fazê-lo (como mover / ocultar postmaster.pid) resultarão em corrupção de dados grave.

— Craig Ringer

@CraigRinger Hm, isso é contraditório com o wiki.postgresql.org/wiki/Shared_Storage ?

— Elleciel

Você pode executá-lo se garantir absolutamente que apenas um postmaster possa acessar o diretório de dados ao mesmo tempo. Um bom STONITH / esgrima é um requisito absoluto para evitar a corrupção de dados em grande escala. Pessoalmente, não há como eu fazer isso. Isso também elimina os benefícios dos quais você está falando - descobrir qual é o servidor principal / ativo automaticamente etc. - porque você precisa gerenciar o failover.

— Craig Ringer

Revisei a página da wiki para torná-la mais clara; Obrigado por apontar isso.

— Craig Ringer

Isso não faz sentido. A solução de alta disponibilidade da Nexenta está alavancando o cluster RSF-1 . Parece que você está fazendo isso com o ZFS no Linux sem a peça RSF-1. Lembre-se, o ZFS no Linux não tem realmente uma opção de cluster, portanto a referência Nexenta não se aplica. O que você ganha com dois nós principais?

— precisa saber é o seguinte

Você não pode ter duas instâncias do Postgres ("clusters" na terminologia do Postgres) agindo nos mesmos arquivos físicos.

se você deseja desempenho, o sharding pode ajudá-lo (duas instâncias, cada uma com dados diferentes)

Se você deseja alta disponibilidade, o failover com o STONITH pode ser a solução. você precisa garantir que o hardware seja reparado e não tente abrir o banco de dados enquanto o segundo nó o estiver servindo.

— Jasen
fonte