Como você atualiza sua base de código de produção / esquema de banco de dados sem causar tempo de inatividade?

41

Quais são algumas técnicas para atualizar o esquema base / banco de dados de um servidor de produção sem causar qualquer tempo de inatividade?

    
por Olivier Lalonde 09.01.2011 / 11:31
fonte

4 respostas

19

Geralmente, os sites em que trabalhei que tinham esse tipo de requisito estavam todos atrás de balanceadores de carga ou tinham locais de failover separados. Neste exemplo, presumo que você tenha um único balanceador de carga, dois servidores da Web (A e B) e dois servidores de banco de dados (M & N - geralmente os servidores de banco de dados são vinculados por meio de registro - pelo menos no SQL Mundo do servidor).

  1. Servidor Web A para ser desconectado do balanceador de carga (assim todo o tráfego de entrada vai para B).
  2. O envio de log está parado (o DB Server M será atualizado primeiro).
  3. Atualizar o servidor da Web A. Aponte a configuração para o Servidor do BD M.
  4. Teste e verifique se a atualização funcionou (geralmente as pessoas estão acessando o endereço IP diretamente).
  5. Defina o balanceador de carga para que as sessões existentes continuem indo para B. Novas sessões vão para A.
  6. Aguarde que todas as sessões expiram em B (pode ser uma meia hora ou mais, geralmente observamos o tráfego e temos uma pausa de 1 hora programada).
  7. Atualização B e N.
  8. Teste e verifique se a atualização funcionou.
  9. Configure o envio de logs novamente e teste-o.
  10. Defina o balanceador de carga para operação normal.

Em aplicações web muito complicadas, o que é descrito como etapas 1-5 pode levar a noite toda e ser uma planilha Excel de 50 páginas com horários e números de contato de emergência. Em tais situações, a atualização de metade do sistema está programada para as 18h às 6h, deixando o sistema disponível para os usuários. O manuseio da atualização para o site de recuperação de desastres geralmente é agendado para a noite seguinte - só espero que nada quebre o primeiro dia.

Onde o tempo de atividade é um requisito, os patches são testados primeiro no ambiente de controle de qualidade, que idealmente é o mesmo hardware da produção. Se eles não mostrarem nenhuma interrupção, eles poderão ser aplicados no horário regular, que geralmente é no fim de semana.

    
por 12.01.2011 / 05:18
fonte
9

Para bancos de dados típicos (Oracle, por exemplo), é possível alterar o esquema do banco de dados enquanto ainda executa consultas em paralelo. Isso requer um planejamento futuro.

Existem algumas restrições para a mudança a ser aplicada:

  • deve funcionar com o código existente, o que significa que o código deve lidar com as versões antiga e nova do esquema
  • não deve incorrer em tal carga no banco de dados que as transações parem de gritar (estou olhando para você CREATE INDEX )
  • não deve incorrer na perda de dados (você não pode descartar e recriar uma tabela)

Para que o esquema seja retrocompatível, você geralmente pode ADICIONAR ou MODIFICAR uma coluna, você pode apenas DROP algo se o código existente não o usar por mais tempo.

Se o seu código não puder manipular a mudança de forma transparente, altere o código antes de alterar o banco de dados.

Um conselho simples sobre o planejamento futuro: sempre explique os nomes das colunas nas suas solicitações de banco de dados (não use SELECT * FROM ). Dessa forma, você não terá novas colunas aparecendo em solicitações antigas.

    
por 09.01.2011 / 12:54
fonte
5

Nem todos os sistemas podem, tem que ser configurado de uma forma que o suporte.

Por exemplo, um dos nossos principais sistemas que ajudei a atualizar há alguns anos deve estar disponível 24 horas por dia, 7 dias por semana. Ela consistia em vários níveis, incluindo uma camada de comunicação pura entre a Camada de Interface do Usuário e a Camada de Negócios off-site. Devido à maneira como a camada de comunicação foi codificada, qualquer mudança futura no esquema Business Layer ou DB pode ser implementada sem uma interrupção real. No pior cenário, um usuário experimentaria uma pausa de 10 a 30 segundos à medida que as alterações entrassem em vigor.

Se as alterações fossem puramente de código para a camada de negócios, elas poderiam ser enfileiradas e "ativadas" com atraso de apenas milissegundos.

Poderia fazer isso porque:

  • A camada de comunicação pode conter mensagens. Isso nos permitiu ter uma interrupção real em qualquer uma das camadas, além da Camada da interface do usuário, sem precisar derrubar a interface do usuário.
  • A camada de negócios gerenciada pelo MVDB é chamada de UniData . Isso contém todo o código na memória. Depois de compilar o código, você pode usar um comando para forçar o novo código de objeto na memória, substituindo o antigo.

Outras técnicas envolvem a replicação de transações para outro espelho do sistema existente. Aplicando a atualização a uma, alternando e repetindo todas as transações feitas entre a atualização e a mudança. YMMV dependendo de seus sistemas embora.

    
por 09.01.2011 / 11:41
fonte
1

Aqui está uma perspectiva diferente, do mundo dos sistemas de bancos de dados incorporados e sistemas embarcados. Os sistemas embarcados incluem vários equipamentos de infra-estrutura de rede / telecomunicações e, nesse domínio, eles costumam falar sobre 99,999% (cinco 9s) de tempo de atividade.

Nós (McObject) somos o fornecedor da família eXtremeDB de produtos de sistemas de banco de dados incorporados, incluindo o eXtremeDB High Availability.

Primeiro, entenda que "banco de dados embutido" significa que o sistema de banco de dados é uma biblioteca que é compilada e vinculada ao código do seu aplicativo; nesse sentido, é "incorporado" na sua aplicação.

Com o eXtremeDB High Availability, há uma instância MASTER de seu aplicativo (que pode ser um ou vários processos) e uma ou mais instâncias REPLICA de seu aplicativo. Quando uma réplica estabelece uma conexão com o mestre, ela recebe uma cópia do banco de dados do mestre por meio de um processo chamado "sincronização inicial". Isso pode ser feito enquanto o aplicativo mestre continua seu trabalho. Uma vez sincronizado, recebe as transações do mestre por meio da replicação. Portanto, uma réplica sempre tem dados atuais e pode assumir (por meio de um processo chamado failover) no caso de falha do mestre.

Um recurso da sincronização inicial é chamado de "evolução do esquema binário". Em inglês claro, isso significa que o processo de preencher o banco de dados da réplica acomodará as diferenças entre o esquema do banco de dados da réplica e o esquema do banco de dados do mestre.

Na prática, isso significa que você pode criar uma versão mais recente do seu aplicativo (com novas / descartadas tabelas, campos novos / eliminados / alterados, índices novos / descartados), anexar essa nova versão de seu aplicativo a um mestre e então faça com que a nova réplica se torne o novo mestre (ou seja, force um failover para a nova réplica para que ela se torne o mestre e o antigo mestre se desligue). Voila, você migrou seu aplicativo da versão N para N + 1, sem interromper a disponibilidade do seu sistema. Agora você pode atualizar o antigo mestre e quaisquer outras réplicas para a versão N + 1.

    
por 08.04.2011 / 23:28
fonte

Tags