Quais servidores de banco de dados não são interrompidos por reinicializações do servidor? (Clusters?)

Question

Fomos solicitados a fornecer um sistema em que o servidor de banco de dados central continua suas operações, mesmo ao aplicar atualizações de segurança ao sistema operacional do servidor ou ao software do servidor de banco de dados. Até onde eu vejo, isso inclui atualizações de segurança que exigem que o (s) servidor (es) reinicialize.

A tecnologia de cluster parece óbvia, mas se um servidor puder realmente reinicializar enquanto o cluster estiver em uso, tenho algumas perguntas:

• Quais produtos de banco de dados podem fazer isso?
• Como isso funciona? Ele armazena os dados do banco de dados em todos os servidores simultaneamente ou as tarefas de um servidor são transferidas para outro enquanto ele está sendo reinicializado?
• Como isso afeta o desempenho, especialmente a latência de consultas?

Answer 1

Nenhuma interrupção durante a manutenção programada, incluindo uma reinicialização do sistema operacional? Oracle RAC. É a única opção real em que posso pensar e, certamente, o único banco de dados de cluster paralelo que eu confiaria para isso. Até mesmo o RAC deve, algumas vezes, ficar inativo para os patches do banco de dados, mas a maioria pode ser aplicada durante a execução.

Se você conseguir lidar com pelo menos 10 a 15 segundos de inatividade, há várias outras opções, incluindo armazenamento em cluster no nível do aplicativo (cluster veritas, cluster da Microsoft, cluster de oracle) ou replicação no nível do banco de dados. Uma infra-estrutura virtual por si só não ajuda muito. O sistema operacional ainda precisa ser desativado.

Também é possível combinar bancos de dados replicados com um cliente multihomed para produção ininterrupta, embora eu não consiga lembrar o nome de tais clientes, no momento, de qualquer maneira.

Eu devo acrescentar que você provavelmente vai querer usar algum tipo de * NIX para mantê-los no mínimo. Tanto quanto me lembro, houve apenas uma atualização que vale a pena reiniciar no RHEL e OEL nos últimos dois anos.

O Oracle RAC é um cluster paralelo. O banco de dados é armazenado em armazenamento compartilhado e acessado por todos os nós simultaneamente. Feito corretamente, deve melhorar o desempenho geral na maioria dos casos e gerar pouca ou nenhuma diferença nos tempos de resposta da consulta. Esta é uma tecnologia complexa, no entanto, e fazer o certo está longe de ser trivial.

Existem algumas outras tecnologias paralelas que prometem cinco noves (99,999% de tempo de atividade, igual a 5 minutos de inatividade por ano), mas elas são muito antigas (VAX) ou muito novas (NDB).

    

Answer 2

A diferença entre um sistema confiável e um com tempo de inatividade zero é a diferença entre colocar um balão de alumínio na órbita baixa da Terra e colocar uma pessoa na lua e recuperá-la com segurança.

Eu olharia para as maneiras antigas de fazer isso, que na minha opinião são aquelas que você deveria estar olhando se você precisa trabalhar pela primeira vez e não estourar o orçamento.

Os antigos padrões são os clusters OpenVMS e o Tandem (agora HP) NonStop. Ambos são projetados para vários computadores que executam exatamente o mesmo banco de dados e o mesmo código. Ambos foram projetados para fornecer 100% de tempo de atividade, mesmo através de atualizações e patches de SO e software. Ambos têm um histórico comprovado de décadas de funcionamento adequado.

Agora - há coisas modernas que irão fornecer isso, no papel. Na prática, você terá problemas como " oops, nós cometeu um erro em nosso servidor de licenças e suas VMs agora não inicializam . " Em uma década, tenho certeza de que essas tecnologias serão testadas e comprovadas como confiáveis, mas, até lá, se você precisar trabalhar, seja muito conservador em quais histórias você acredita.

E, finalmente, a coisa mais importante para tornar um sistema confiável é projetá-lo bem, construí-lo bem e cuidar bem dele porque, na prática, a coisa menos confiável na equação é a pessoa por trás do teclado.

    

Answer 3

Cluster do MySQL link

• Arquitetura Shared Nothing (o armazenamento central não é obrigatório).
• Rolling upgrades - atualize sem parar o cluster.
• Você pode especificar quantas cópias de seus dados devem existir no cluster.
• Historicamente, foi um banco de dados em memória, o que significa que o banco de dados total não pode exceder a quantidade de RAM em seu cluster (menos a sobrecarga para replicação).
• Agora também suporta bancos de dados em disco.
• Não possui todos os recursos de alguns dos outros mecanismos de armazenamento do MySQL.

Answer 4

Existem algumas maneiras de fazer isso. Clusters no nível do sistema operacional podem funcionar, com uma breve interrupção quando você passa de um nó para outro. Você não especificou sua plataforma de sistema operacional. A maioria das plataformas? NIX possui uma solução de cluster robusta.

No que diz respeito à plataforma de banco de dados, a Oracle tem sua abordagem de tudo compartilhado com o RAC, na qual você pode desativar um único nó e tudo será movido para outro (s) nó (s) no cluster. Ele permite fazer manutenção em um nó enquanto os outros nós continuam em execução e atendendo aos clientes. Todos eles utilizam o mesmo conjunto de discos. O efeito no desempenho depende do dimensionamento do hardware, a maioria dos lugares dimensiona seu hardware para capacidade N + 1 para garantir que o desempenho não seja afetado durante esse tipo de atividade.

O Informix tem algo parecido agora em seu último lançamento. O DB2 deve obter isso em breve.

    

Answer 5

Acredito que a única maneira de fazer isso é usar o armazenamento em cluster . Você precisará de vários servidores de banco de dados que são combinados em um cluster. Então, um servidor pode assumir automaticamente para outro que falhou. Isso é conhecido como "failover" (ou cluster de alta disponibilidade).

Para resolver suas dúvidas:

Which database products can do this?

Tudo o que anunciam "suporte de cluster". Eu sei que pelo menos o MySQL e o Oracle o fazem, mas muitos outros DBMS provavelmente também o suportam.

How does it work? Does it store the database data on all servers simultaneously, or is one server's tasks transferred to another while it is rebooting?

Ambos. Os servidores regularmente sincronizam seus dados, de modo que são mantidos em todos os servidores. Quanto a qual servidor realmente responde às solicitações, há duas opções: Em um cluster de balanceamento de carga, todos os servidores compartilham a carga (para obter melhor desempenho), em um cluster de alta disponibilidade, um computador normalmente faz o trabalho e o sobressalente assume se falhar (failover).

How does it affect performance, especially latency of queries?

Desculpe, não tenho experiência com isso. Normalmente, a sobrecarga deve ser mínima, mas o failover pode levar algum tempo e causar tempos limite.

    

Answer 6

Eu não ouvi falar de algumas das outras soluções mencionadas, então não posso me comparar a elas, mas como eu não vejo a que eu estou acostumada aqui, eu mencionarei isso também.

Isso é o MySQL em cima de um sistema de arquivos DRBD . Com o heartbeat do linux conforme descrito aqui

Nós usamos isso por um par de anos sem tempo de inatividade real. Nosso único problema foi que rodamos nosso cluster em máquinas virtuais, e ele realmente precisa estar em caixas físicas com vários caminhos entre elas (como ethernet e cabo serial, etc)

A maneira como isso funciona é que o DRBD é como invadir várias máquinas , onde mantém o sistema de arquivos subjacente em sincronia contínua entre dois ou mais hosts, enquanto a pulsação só permite que o sistema de arquivos / banco de dados seja apenas viver em um servidor de cada vez.

O failover quando um desce é muito rápido - e pode ser ajustado para ser ainda mais rápido se as conexões entre as máquinas forem redundantes e muito confiáveis. (este foi o nosso problema usando máquinas virtuais). Além disso, ao falhar antes de uma reinicialização agendada, até isso pode ser minimizado.

    

Answer 7

2 maneiras de fazer isso, o VMware FT (limitado a 1 CPU) e o outro é a tecnologia de cluster.

O VMware FT tem 0 problemas de latência, MAS você está limitado a 1 CPU, e a solução de cluster geralmente tem um tempo de "failover" de 15 segundos à medida que a sessão TCP faz failover para o novo servidor e o tempo limite de sessões TCP incluindo a atualização do ARP na rede local.

    

Answer 8

O MS SQL pode agrupar em vários servidores - requer um disco compartilhado de um servidor diferente. O MySQL pode replicar dados com relacionamento mestre / escravo em vários nós. O Oracle RAC criará um cluster com vários nós. O servidor do Sybase rep pode replicar dados em vários servidores.

E, sim, você poderia simplesmente executar tudo no VMWare e, em seguida, usar o FT ou o Motion para mover o SO entre os nós em execução com os dados armazenados em uma SAN.

    

Answer 9

Eu diria que uma maneira de fazer isso seria a replicação master-master usando o MySQL. Certifique-se de que seu aplicativo é multihomed para usar o segundo mestre, se o primeiro não estiver disponível, então você pode trazer um único mestre para baixo enquanto o outro permanece ativo para leituras e gravações. Quando o segundo servidor voltar, basta virar na outra direção. Inserções de tabela acontecem com valores de PK espaçados 2 separados em vez de 1 separados, mas isso é bom, é apenas uma chave.

    

Answer 10

I look for solutions that can keep the transaction open, even when the machine, on which the database server software is installed (Virtual or physical) is rebooting.

Acho que você precisará analisar o HA-JDBC para atender a esse requisito: link

"Tolerância de alta disponibilidade / falha - Um cluster de banco de dados HA-JDBC pode perder um nó sem falhar / corromper transações abertas."

Felicidades

    

Answer 11

MSSQL com Windows Clustering lidaria com 0 janelas de manutenção de tempo de inatividade FORNECIDO você falha no nó em que vai trabalhar ANTES de começar a trabalhar. Além disso, você precisará configurar o NLB nos hosts para garantir que todas as conexões sejam tratadas por meio de um endereço IP compartilhado (caso contrário, pode haver dois ou mais segundos de inatividade enquanto os servidores tentam novamente o DNS, etc). Para fazer o clustering funcionar, você precisará de um storage array compartilhado, como o iSCSI, e dois ou mais hosts físicos (os Hypervisors também precisam de atualizações).

Aqui estão algumas informações muito boas sobre como seria esse ambiente, mas basicamente se você não pode ter tempo de inatividade, você precisará ter pelo menos um DBA do MS SQL na equipe e de plantão para garantir que todos os failovers ocorram corretamente, e Você não pode ir barato em qualquer coisa. Ligue para a Microsoft e leia seu livro sobre isso, ou melhor ainda, coloque seu aplicativo na nuvem no Azure ou em um fornecedor de servidor dedicado especializado em alta disponibilidade.

link