Um programador deve manter as bases de dados no nó de computação ou no nó de armazenamento?

Mantenha, por defeito, os ficheiros de bases de dados ativos num armazenamento de baixa latência junto à computação e utilize o nó de armazenamento para cópias de segurança, dumps, réplicas e arquivos.

Esse valor predefinido muda quando o nó de armazenamento disponibiliza um caminho de armazenamento em blocos concebido de forma deliberada, com latência medida, semântica de durabilidade correta e um benefício de recuperação que justifique a dependência adicional. A decisão não se resume simplesmente a capacidade local versus capacidade de rede: os registos de transações, os ficheiros de dados, as cópias de segurança, os uploads da aplicação e as bases de dados de teste descartáveis têm diferentes padrões de escrita e consequências em caso de falha.

Separe o estado da base de dados dos dumps e das cópias de segurança

Mapeie todos os caminhos relacionados com a base de dados antes de escolher um nó. O diretório de dados principal e o registo de transações representam o estado ativo; exigem uma ordenação consistente das escritas e uma latência previsível. Os dumps lógicos, as cópias de segurança base, os registos arquivados, as exportações e os ficheiros carregados pela aplicação têm padrões de acesso diferentes e, muitas vezes, podem atravessar a rede em segurança.

Não monte uma única partilha NAS e coloque tudo lá dentro. Mantenha o volume ativo da base de dados separado dos destinos das cópias de segurança e dos dados de aplicações em massa. Assim, é possível ajustar, monitorizar, encher, criar snapshots, restaurar e migrar cada função sem fingir que todos os bytes persistentes precisam do mesmo suporte.

Para bases de dados de branches de curta duração ou testes de CI, o tempo de reconstrução pode ser mais importante do que a durabilidade. Coloque-as num armazenamento local rápido e recrie-as a partir de migrações ou seeds anonimizadas. Para a base de dados de serviço diária de um programador, trate uma falha do SSD local como um evento de recuperação e mantenha a cópia remota suficientemente atualizada para cumprir o ponto de recuperação declarado.

Meça o caminho de escrita antes de escolher um nó

O desempenho da base de dados depende de mais do que do débito sequencial. Meça a latência dos commits síncronos, as leituras e escritas aleatórias, a profundidade da fila durante o tráfego de cópias de segurança e o comportamento quando o caminho de rede fica bloqueado. Uma ligação 10GbE pode transferir ficheiros grandes rapidamente e, ainda assim, acrescentar latência e outro ponto de falha a cada transação.

Uma comparação publicada do PostgreSQL concluiu que o NVMe local proporcionava uma latência inferior e mais previsível do que os serviços de cloud testados ligados através da rede, embora também salientasse as vantagens de elasticidade e durabilidade do armazenamento de rede. Esses benchmarks do PostgreSQL local e ligado à rede não constituem uma garantia para um laboratório doméstico, mas mostram por que razão a colocação da base de dados precisa de medições da carga de trabalho, e não apenas da velocidade da interface.

Execute um teste representativo com o mesmo sistema de ficheiros, as mesmas definições de sincronização, a mesma versão da base de dados, o mesmo conjunto de dados e a mesma simultaneidade planeados para o serviço. Durante o teste, inicie uma cópia de segurança grande ou uma transferência de multimédia na rede de armazenamento. Se a latência de cauda ou o tempo de commit se tornar irregular, a capacidade central não está a compensar o caminho partilhado.

Coloque, por defeito, os ficheiros da base de dados principal junto à computação

Para um programador, um nó de computação e bases de dados moderadas, SSDs locais em espelho ou um volume local recuperável costumam proporcionar a responsabilidade mais clara. O processo da base de dados, os respetivos ficheiros de dados e o respetivo registo write-ahead falham em conjunto, enquanto o nó de armazenamento recebe cópias de segurança através de um processo consciente da base de dados, em vez de alojar remotamente um sistema de ficheiros sempre aberto.

A colocação local não significa utilizar uma única unidade de arranque sem proteção. Separe o volume da base de dados do sistema operativo sempre que for prático, monitorize o espaço livre e o estado das unidades, reserve capacidade para operações de manutenção e exporte cópias de segurança antes das atualizações. Fixe a colocação de contentores ou máquinas virtuais para que um agendador não inicie a base de dados noutro nó sem o respetivo estado.

Utilize armazenamento local apenas quando o caminho de recuperação for real. Se substituir o nó de computação exigir adivinhar com base numa cópia desatualizada, o armazenamento centralizado pode expor uma falha de cópia de segurança existente em vez de a criar. Corrija o fluxo de cópia de segurança e restauro antes de otimizar o caminho dos dados.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utilize o nó de armazenamento para cópias de segurança, réplicas e arquivos

Um nó de armazenamento é valioso quando recebe dumps consistentes com a aplicação, cópias de segurança base, registos de transações arquivados, snapshots imutáveis ou uma réplica da base de dados com uma finalidade própria de recuperação. Também pode alojar anexos grandes ou exportações analíticas, enquanto o catálogo e os registos da base de dados sensíveis à latência permanecem locais.

Os testes da comunidade de PostgreSQL sobre NFS num servidor de armazenamento produziram resultados contraintuitivos e questões de configuração, em vez de uma resposta universal. É por isso que deve tratar o armazenamento primário remoto como uma exceção concebida de forma específica: valide o comportamento de sincronização, o tratamento de falhas, as opções de montagem, a semântica da cache e a recuperação na stack exata.

Valide a recuperação após falhas e o gatilho de migração

Teste quatro eventos: reinicie a base de dados de forma limpa, provoque uma falha do nó de computação durante as escritas, interrompa a ligação de armazenamento durante uma cópia de segurança e restaure para um anfitrião vazio. Confirme o ponto de recuperação, o tempo de recuperação, as verificações de integridade da base de dados e o comportamento de reconexão da aplicação. Um benchmark normal rápido não prova que o caminho de escrita interrompido é seguro.

A configuração é aprovada quando os dados ativos têm uma latência previsível, as cópias de segurança não conseguem substituir nem bloquear a base de dados principal e um nó de computação de substituição consegue restaurar sem pressupostos de armazenamento não documentados. Mova os ficheiros principais para um serviço de armazenamento concebido para o efeito apenas quando os benefícios medidos de recuperação ou mobilidade superarem a dependência da rede; mova-os de volta para o armazenamento local quando a latência de cauda ou as interrupções da ligação se tornarem a principal fonte de incidentes.

Para uma decisão sobre a arquitetura mais ampla, a comparação da ZimaSpace entre uma NAS orientado para o armazenamento e um servidor doméstico orientado para a computação ajuda a decidir que função deve permanecer estável à medida que as cargas de trabalho de desenvolvimento mudam.

Regra final de configuração

Por defeito, utilize armazenamento SSD local e protegido para os ficheiros ativos da base de dados e o nó de armazenamento para cópias de segurança verificadas, arquivos e réplicas selecionadas. Escolha armazenamento primário remoto apenas depois de medir a semântica das escritas, a latência de cauda, o comportamento durante interrupções e a vantagem de recuperação.