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:
- Backups - os plugins innodb são ótimos e tudo, mas o tempo de backup em tantos dados não é tão prático
- 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
- 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)
- 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:
- 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.
- 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.
- 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.
- 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.