Quais práticas ou ferramentas permitem a implantação contínua de bancos de dados?

Entrega Contínua ou Implantação Contínua de infraestrutura e código é comparativamente simples comparado a tentar as mesmas abordagens para bancos de dados, especificamente RDBMSs. O código e a infraestrutura não serão alterados ou evoluirão após a conclusão da implantação. Os bancos de dados, no entanto, terão novos dados adicionados, tornando os dados, se não os componentes inerentemente mutáveis ​​do esquema.

Estou ciente de que existem práticas como apenas adicionar objetos de banco de dados, ou seja, tabelas e colunas, nunca modificá-los ou removê-los - essa maneira puramente aditiva de abordar esquemas de banco de dados tem a vantagem de garantir que os esquemas sejam compatíveis com versões anteriores ao custo de sucessivamente mais complicado esquemas.

Da mesma forma, existem produtos como Flyway e Ready Roll que ajudam na gravação de migrações a serem gravadas entre as versões de um esquema.

Quais outras práticas e ferramentas existem atualmente para permitir a implantação contínua de esquemas de banco de dados em um ambiente de produção em que a integridade dos dados é preocupante?

Pramod Sadalage e Scott Ambler escreveram um livro Refactoring Databases: Evolutionary Database Design, que é uma cartilha incrivelmente sólida para o assunto de DBs em uma organização / equipe de CD.

Os desafios

Estou ciente de que existem práticas como adicionar apenas objetos de banco de dados, como tabelas e colunas, nunca modificá-los ou removê-los

Em uma empresa em que trabalhei, uma janela rolante de dados brutos equivalia a cerca de 6 meses e consumia 10 TB. Os dados foram então processados ​​em um formato RDBMS, que custou 6 TB de dados utilizáveis, responsáveis ​​por cerca de 10 anos de dados reportáveis. O ponto é que, em escala, esses tipos de práticas simplesmente não são práticos. O armazenamento é caro - provavelmente a maior despesa de computação. Isso oferece vários desafios interessantes:

1. Backups - os plugins innodb são ótimos e tudo, mas o tempo de backup em tantos dados não é tão prático
2. Tempos de restauração - para grandes conjuntos de dados - especialmente se você precisar de replicação para recuperar o atraso depois que uma restauração voltar ao estado operacional pode levar dias ou até semanas
3. Criando / propagando novas instâncias - Geralmente, o trabalho que você pode realizar no desenvolvimento / teste envolve trabalhos ETL (Extrair, Transformar e Carregar) no seu conjunto de dados. Eles precisam ser validados usando unidades de teste de controle de qualidade, mas isso deve ser feito de maneira não destrutiva, para que o conjunto de dados de produção original seja preservado. Em um desastre, você pode estar disposto a lidar com um longo tempo de restauração, entendendo que os backups são uma apólice de seguro e a intenção é evitá-los, o fluxo de trabalho de desenvolvimento do DevOps exige que, essencialmente, você possa executar uma restauração ou cópia dos seus dados regularmente (talvez várias vezes ao dia)
4. Capacidade - Incluir tantos dados na escala que acabei de descrever pode exigir muito de E / S. Você não apenas precisa solucionar os problemas descritos em 1-3, mas precisa fazê-lo de uma maneira que não cause interrupções ou lentidão no desempenho de seus sistemas de produção.

Embora as considerações acima possam não ser uma preocupação em escalas menores, em escalas maiores, elas se tornam enormes problemas. Isso significa que é extremamente importante que você defina seus requisitos e preveja o tamanho do seu conjunto de dados.

Definindo requisitos

Como resultado, você precisa definir vários requisitos:

1. RTO - RTO ou objetivo de tempo de restauração para backups é um dos drivers mais importantes das soluções de backup de banco de dados. Embora, a princípio, possa não parecer relevante para a maioria dos outros problemas, ele se torna extremamente relevante quando você pergunta "E se eu usasse minha solução de backup para criar ou propagar novas instâncias?". Vou abordar algumas técnicas para fazer isso na próxima seção.
2. RPO - RPO ou Objetivo do Ponto de Restauração para backups define A) a quanto tempo você pode restaurar (minutos, horas, dias, semanas, meses ou anos) B) O intervalo de backup em diferentes camadas e C) quão granularmente você pode restaurar . Por exemplo, para bancos de dados de email, os Backups de nível de mensagem - restaurando um email específico - são frequentemente solicitados. Da mesma forma, você pode achar que os dados em alguns dias são completamente inúteis - portanto, não faz sentido restaurar um ano.
3. Tamanho do seu conjunto de dados - Isso é importante porque, para um banco de dados de 1 MB, seu RTO pode ser alcançado com a maioria dos produtos e soluções de backup. No entanto, para um banco de dados de 10 TB, você descobrirá que um backup completo em nível de linha da fita LTO 3 provavelmente não alcançará o seu RTO e poderá interferir no seu RPO porque os backups começam a exceder sua janela de backup. Você não pode exatamente fazer um mysqldump neste grande conjunto de dados, mas provavelmente poderia se safar disso no banco de dados de 1 MB.
4. Consistência do banco de dados - Uma coisa final que faz uma imensa diferença na implantação contínua, confiabilidade do site, escalabilidade e alta disponibilidade ao trabalhar com bancos de dados é a sua necessidade (ou falta dela) de consistência. Existem três tipos básicos: consistência imediata, consistência Just-In-Time (JIT) e consistência eventual

Além das considerações principais acima, você também precisa considerar os requisitos de licenciamento e suporte (código aberto ou código fechado; suporte interno, suporte de terceiros ou suporte ao fornecedor) requisitos de aplicativo / idioma (os conectores para muitos bancos de dados podem ser importantes; é seu aplicativo compilado? Você tem acesso ao código-fonte? Você pode recompilá-lo ou é fornecido por um fornecedor? Ou ele roda em uma linguagem interpretada?) requisitos políticos (sua organização confia apenas no Oracle? Eles odeiam oracle ? Eles não confiam no MySql? Como você se sente sobre o MariaDB ou o Postgres?) E o mecanismo de banco de dados (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) E os requisitos históricos ou de compatibilidade (usamos PL / SQL por anos e metade do nosso código está embutido no mecanismo Oracle! Como poderíamos portar para o MariaDB?!?)

Todas essas coisas (significativamente) afetam as ferramentas disponíveis para você.

Algumas opções para gerenciamento de dados interno

Nota: O seguinte não é de forma alguma exaustivo, e outros usuários do SE devem entrar em contato com sugestões adicionais.

Com as considerações genéricas fora do caminho, deixe-me fornecer algumas técnicas e tecnologias para abordar as questões acima. Primeiro, pergunte a si mesmo se você realmente precisa usar um RDBMS ou se dados não estruturados com algo como Hadoop, CouchDB ou mesmo Armazenamento Orientado a Objetos (algo como swift) são uma opção.

Segundo, considere procurar uma solução baseada em nuvem. Isso terceiriza parte dessa dor de cabeça e deixa os problemas complicados para indivíduos altamente qualificados (e pagos). Porém, em escala, você pode achar que isso realmente consome seu orçamento (os provedores de nuvem lucram com isso e, em uma certa escala, você pode empregar esses especialistas sozinho) ou se estiver trabalhando sob segurança ou política específica. requisitos (leia-se: não podemos fazer nuvens), considere um NFS / FibreChannel Filer híbrido. A maioria desses arquivadores, como os da NetApp, Pure Storage e Tegile, suporta uma técnica de clonagem e instantâneo baseada em delta que pode ser muito útil para A) fazer backups, B) Restaurar backups e C) Semear novos backups.

Nesse ponto, preciso observar que não sou especialista em backup e armazenamento; portanto, há algumas partes desse problema que nunca consegui resolver antes de passar para outros problemas (e pastagens mais ecológicas).

Mas , dito isso, esses produtos permitem tirar instantâneos diferenciais embaixo do seu banco de dados. Você precisará criar um script completo de "tabelas de bloqueio com bloqueio de leitura" em uma de suas instâncias de banco de dados (recomenda-se um escravo somente leitura) e despejar sua posição no binlog ou GTID, mas para esses arquivadores, quando você fizer isso, poderá para usar esses snaps para criar novas instâncias do seu banco de dados. Você deseja colocar os binlogs em uma partição separada e colocar apenas os dados do banco de dados nessas partições. Depois de fazer isso, você poderá clonar essas partições (no NetApps, isso é conhecido como " FlexClone "

Isso ocorre porque, para cada bloco lido, o arquivador deve determinar se os dados residem no instantâneo original congelado ou no delta. Para volumes / lojas com vários instantâneos, isso pode precisar ser verificado várias vezes. Você pode superar isso atualizando os dados (ou seja, descartar seu instantâneo e cloná-lo novamente periodicamente - o que pode acontecer natural e organicamente para um bom ambiente de implantação contínua) ou dividir permanentemente o volume (conhecido como "Flex Split" na terminologia NetApp ), que levará um momento para resolver permanentemente os deltas e criar um volume totalmente novo e separado.

Esses clones delta têm o benefício adicional de reduzir seus requisitos gerais de armazenamento - você pode gerar vários clones ou instâncias dos dados do banco de dados de produção para fazer seu desenvolvimento, teste e validação. Se você estiver mantendo apenas uma cópia do seu grande conjunto de dados, além dos pequenos deltas (o que provavelmente serão), reduzirá o custo e a área de armazenamento geral.

O único truque aqui é que isso pode não constituir uma solução de backup completo, pois o "backup" ainda reside no seu arquivador. Para isso, pode ser necessário usar algo que a NetApp chama de Snap Mirror, que espelhará os dados (usando a tecnologia estilo rsync) entre arquivadores e até datacenters, ou usar algum tipo de solução de backup integrada que pode fazer backup em fita de um de seus snapshots delta ou clone flexível.

No entanto, isso tem uma falha importante: todos os seus dados - dev, test and prod ainda estão usando E / S no mesmo arquivador e cabeça de armazenamento. Para contornar isso, considere criar uma instância de banco de dados escravo em um segundo arquivador que possa ser o ponto de propagação para o arquivador de teste e / ou desenvolvedor, ou considere usar um controlador de entrega de balanceador de carga / entrega de aplicativos para que a camada de aplicativos espelhe as solicitações de produção em seu ambiente (s) de teste (e / ou dev). Isso tem o benefício adicional de lançar tráfego de produção em seu ambiente de QA / Test antes de promover a produção para problemas que podem não ser percebidos imediatamente. Em seguida, você pode verificar se há erros nos logs com base no tráfego de produção e no comportamento do usuário.

Isso permitirá que você use alguns scripts para gerar e destruir programaticamente conjuntos de dados inteiros (e grandes) para uso com metodologias de implantação contínua.

Escalabilidade e alta disponibilidade

Embora você tenha perguntado sobre a implantação contínua, o DevOps se preocupa com mais do que apenas uma implantação contínua - por isso vou incluir alguns bits sobre redundância, escalabilidade e alta disponibilidade.

Mencionei, JIT, consistência imediata e eventual. É aqui que entram diversos mecanismos RDBMS. A consistência eventual é relativamente fácil, basta configurar a replicação assíncrona circular. Entretanto, isso pode causar algumas colisões * (e se a camada de aplicativos atualizar os dados de um lado do cluster e do outro lado antes da conclusão da replicação?) Para obter consistência imediata, observe o cluster Galera que forçará a replicação síncrona, mas causa problemas de escalabilidade (como você irá replicar para o site do Disaster Recovery ou equilibrar a carga geograficamente sem incorrer em latência significativa devido ao atraso na propagação na camada de rede?) mas isso parece o pior dos dois mundos.

Normalmente, no entanto, a maioria das pessoas não precisa de replicação totalmente síncrona - isso geralmente é necessário apenas para ambientes muito específicos (e exóticos) de alta gravação, nos quais vários mestres são necessários com o compartilhamento de tabelas. A maioria dos aplicativos pode lidar com a consistência Just-In-Time usando um proxy de banco de dados. Por exemplo, o ScaleArc monitora o status da replicação e rastreia aonde as gravações acabaram (para enviar solicitações de leitura subesquentes até a replicação ser atualizada) para fornecer consistência e aparência just-in-timede consistência do banco de dados. O ScaleArc é compatível com Postgres, MySQL, MariaDB, Oracle e MSSQL e pode usar expressões regulares para fragmentar / particionar seus bancos de dados para aplicativos que não podem usar chaves de fragmento. Ele também possui uma API REST robusta para o seu software de gerenciamento de configurações interagir - e sua equipe de suporte é excelente

Da mesma forma, você pode considerar uma alternativa gratuita, MaxScale , desenvolvida pela equipe do MariaDB para o MariaDB. No entanto, não possui a GUI e alguns dos recursos de armazenamento em cache do ScaleArc.

Finalmente, a estrutura do MySQL (e apenas o MySQL Cluster na RAM - se você puder pagar tanta RAM) são outros potenciais - especialmente com o novo proxy do MySQL. Isso pode fornecer o componente de escalabilidade e redundância para o seu ambiente.

O Postgres e o Oracle devem ter os recursos de replicação e sharding de que você precisa, mas o ScaleArc será bem pareado se você precisar de um proxy.

Por fim, todas essas partes se somam a um ambiente altamente flexível adequado para implantação e desenvolvimento contínuos se você não puder simplesmente usar um ambiente baseado em nuvem e deixar que seu provedor de nuvem lide com os problemas acima.

Usamos o Flyway no trabalho para gerenciar esquemas do Postgres no aplicativo e o Pillar para gerenciar os esquemas do Cassandra. Achamos melhor se o aplicativo gerencia seu próprio esquema.

Tivemos uma experiência horrível com o ansible gerenciar esquemas antes dos aplicativos gerenciarem seus próprios esquemas.

Eu diria que uma ferramenta sozinha não ajudará realmente, a menos que você transfira a responsabilidade do esquema para a equipe de aplicativos.

Fazemos uso liquibase ou flyway no trabalho, onde a equipe de aplicação é responsável para criar os changesets.

Junto com isso, você pode evitar uma maneira puramente aditiva.
Cada aplicativo deve ser compatível com sua versão anterior, quando uma alteração do esquema tiver que ser feita, o aplicativo integrará uma nova coluna no esquema, gravará nele e ainda lerá e gravará da / para a coluna anterior (permitindo que o versão anterior ainda tenha os mesmos dados).
A próxima versão do aplicativo pode parar de atualizar a coluna antiga e somente a terceira versão poderá remover a coluna agora não utilizada.

Obviamente, são necessários backups regulares caso algo dê errado.
Um subconjunto adequado de dados com probabilidade de criar problemas nos testes de integração para evitá-los na produção também é uma boa idéia. O caso ideal obtém um subconjunto anônimo de dados de produção.

Usamos o liquibase em nosso trabalho e falarei muito por isso. Também é usado por nossa ferramenta de controle de qualidade, QASymphony .

Estamos utilizando-o internamente nos bancos de dados MSSQL e Oracle e o QASymphony usa / o usou com as instâncias postgres + mysql.

Para responder a essa pergunta no contexto de um ambiente de mainframe e específico aos bancos de dados DB2®, normalmente existem 2 alternativas comumente usadas (não baratas ...) para escolher:

• Administração de Objetos para DB2 , da BMC. Aqui estão alguns detalhes sobre isso (citação da página vinculada):

  Fazer alterações nos objetos em seu banco de dados - ou mesmo realizar tarefas administrativas rotineiras - pode ser um trabalho difícil e arriscado. Há dezenas de tarefas para acompanhar, e um único passo em falso pode ter um impacto desastroso na disponibilidade e na integridade dos dados. Você pode reduzir esforços e riscos com o BMC Object Administration para DB2 11, uma coleção de ferramentas para ajudá-lo:

  • Reduza o tempo necessário para administrar ambientes DB2 complexos e diferentes.
  • Automatize tarefas de rotina durante todo o ciclo de vida do aplicativo para melhorar a integridade.
  • Melhore a produtividade com a navegação simplificada do catálogo do DB2 e o gerenciamento de mudanças.
  • Aprimore a disponibilidade do aplicativo executando alterações e manutenção com interrupções mínimas.

• Ferramenta de Administração do DB2 para z / OS , da IBM.

  Ele simplifica as tarefas complexas associadas ao gerenciamento seguro de objetos e esquemas do DB2 durante todo o ciclo de vida do aplicativo, com o menor impacto possível à disponibilidade.

  • Permite que os usuários naveguem no catálogo do DB2 de maneira rápida e fácil
  • Cria e executa instruções SQL dinâmicas sem conhecer a sintaxe exata do SQL
  • Gerencia e rastreia as alterações feitas nas definições de objeto do DB2, resolvendo possíveis conflitos antes da execução
  • Ajuda a construir comandos do DB2 para serem executados em bancos de dados e tabelas
  • Permite aos usuários criar, alterar, migrar, descartar e fazer engenharia reversa de objetos do DB2
  • Cria e executa trabalhos de utilidade, permitindo que os usuários aproveitem os LISTDEFs e os MODPLATEs para aumentar a produtividade

Integração com ferramentas SCM

Algum tempo atrás, fui desafiado por um cliente a "integrar" a alternativa BMC em seu ciclo de vida do SCM (gerenciado pelo SERENA ChangeMan ZMF ). A idéia por trás dessa integração é " Considere nossa equipe de DBA do DB2 (fazendo coisas com DDLs) como um caso especial de uma equipe de desenvolvimento, usando acidentalmente algum editor exótico (a ferramenta BMC) para produzir o código (DDL) a ser migrado ".

O único desafio (mas real !) Dessa integração foi facilitar também a "reinicialização", que é um dos principais benefícios dessa ferramenta de DBA:

• A capacidade de reinicialização significa que, quando essa ferramenta DBA está realizando suas tarefas (por vezes, com tarefas de longa execução, de acordo com a natureza do trabalho a ser concluído), coisas inesperadas podem acontecer (impasses, interrupções no tempo etc.).

• Se alguma dessas coisas acontecer e você não desejar reiniciar do backup (antes de começar), a ferramenta DBA espera que você reinicie do (ponto de verificação) a partir do qual as coisas começaram a dar errado (e de onde você quer que tudo seja reexecutado).

• Melhor ainda (ou devo dizer "ainda pior"?), Se um novato na ferramenta DBA não souber como reiniciar desse ponto de verificação e simplesmente tentar novamente (desde o início), a ferramenta DBA simplesmente falhará com algum tipo de erro do usuário. E isso com uma indicação com algo como " Até que você me diga como quer que eu prossiga após o meu último ponto de falha, eu me recuso a fazer qualquer coisa (para não piorar as coisas) ".

• No final, a pista real para implementar essa capacidade de reinicialização na ferramenta SCM sendo usada exigia que a ferramenta SCM também fosse ajustada. Na verdade, para permitir que ele seja usado para reiniciar procedimentos SCM com falha (geralmente relacionados a entregas para ambientes de teste / produto de destino) ... em vez de apenas enviar o procedimento SCM com falha novamente (que é a maneira como normalmente essas ferramentas SCM se recuperam dessas situações )

Bônus: após a conclusão da integração SCM da alternativa BMC, o cliente decidiu mudar sua ferramenta DBA para a alternativa IBM. E mesmo que as duas alternativas não pareçam iguais, o impacto disso na integração do SCM foi bastante mínimo: simplesmente uma questão de substituir (em alguma customização reutilizável do SCM) algumas chamadas para a alternativa BMC pelas chamadas equivalentes para a IBM alternativa ... que (usando a terminologia do DevOps) foi implementada por feature-flags / feature-toggles .