💸 👨🏿‍🚀 🎒 Livro “Bancos de dados. Engenharia de Confiabilidade 🛒 💪 👩🏼‍🤝‍👨🏽

Olá, habrozhiteli! No campo da TI, ocorreu uma verdadeira revolução - eles começaram a trabalhar com a infraestrutura e com o código. Esse processo cria não apenas novos problemas, mas também oportunidades para garantir o tempo de atividade dos bancos de dados. Os autores prepararam este guia prático para quem deseja ingressar na comunidade de engenheiros de confiabilidade de banco de dados modernos (DBRE).

Neste livro: • requisitos de armazenamento e requisitos de gerenciamento de riscos. • Criação e desenvolvimento de uma arquitetura que fornece suporte transparente ao banco de dados. • simplificando o processo de gerenciamento de liberação. • armazenamento, indexação e replicação de dados. • determinar as características do data warehouse e selecionar as melhores opções para seu uso. • pesquisa de componentes de arquitetura e criação de arquiteturas orientadas ao processamento de big data.

Para quem é este livro?

, , . , . , . , , . .

, Linux/Unix, - / . , — — — . , , .

, , , . , , .

, , . , - , . , Excel, .

Estrutura de publicação

. . , , , . : , , , . , . !

, : (DBRE), (RE). , . DBR- , , .

, . . , . — , . , , , , , , , . .
, .

1 . , — , DBRE, — , , DBRE .

2 . , . , , — , . , .
3 . . .

4 . . , , . , .

5 6 . . , , , , , .

7 . , , DBE. — , . , , , .

8 . , ? SQL? — , .

9 . . .

10 , . , , . , .

11 . , , . , , , .

12 (), , , . , « » () , , . — .

, 13 . , .

Restauração de backup

Nos capítulos 5 e 6, focamos no design e gerenciamento de infraestrutura. Isso significa que você tem uma boa idéia de como criar e implantar infra-estruturas distribuídas nas quais os bancos de dados funcionam, além de gerenciá-los. Examinamos métodos para adicionar rapidamente novos nós para aumentar a capacidade ou substituir um nó com falha. Agora é hora de discutir o mais importante: fazer backup e restaurar dados.

Vamos ser sinceros: todo mundo pensa em fazer backup e restaurar atividades tediosas e chatas. Para a maioria, esses procedimentos são o epítome da rotina. A equipe não gosta de interagir com engenheiros juniores e contratados externos e trabalhar com ferramentas de terceiros. Antes, tínhamos que lidar com apenas um software de backup terrível. Simpatizamos com você, honestamente.

No entanto, este é um dos processos mais significativos em seu trabalho. Mover dados importantes entre nós, datacenters e transferi-los para arquivos de longo prazo é um movimento constante do ativo mais valioso do seu negócio - as informações. É altamente recomendável que você não considere as operações de recuperação e backup como operações de segunda classe, mas as trate como operações VIP. Todos devem não apenas entender os objetivos da recuperação de dados, mas também estar familiarizados com os princípios deste trabalho e monitoramento de processos. A filosofia do DevOps supõe que todos devem poder escrever código e implementá-lo em um sistema realmente funcional. Convidamos cada engenheiro a participar de processos críticos de recuperação de dados pelo menos uma vez.

Criamos e armazenamos cópias de dados - backups e arquivos - como um meio de atender a uma necessidade específica. Eles são necessários para a recuperação. Às vezes, a recuperação é agradável e descontraída, por exemplo, ao criar um ambiente para auditores ou criar um ambiente alternativo. Mas, na maioria das vezes, é necessário substituir rapidamente os nós com falha ou aumentar a capacidade dos clusters existentes.

Hoje, em ambientes distribuídos, estamos enfrentando novos desafios no backup e recuperação de dados. Como antes, a maioria dos conjuntos de dados locais é distribuída dentro de limites razoáveis, até no máximo alguns terabytes. A diferença é que esses conjuntos de dados locais são apenas parte de um grande conjunto distribuído. A recuperação do site é um processo relativamente controlado, mas manter o estado em um cluster é uma tarefa mais difícil.

Princípios básicos

Começamos discutindo os princípios básicos de backup e recuperação de dados. Para um especialista em banco de dados ou engenheiro de sistema experiente, alguns deles podem parecer elementares. Nesse caso, você pode rolar facilmente várias páginas.

Físico ou lógico?

Um backup físico do banco de dados faz backup dos arquivos reais nos quais os dados são armazenados. Isso significa que os formatos de arquivo típicos do banco de dados são suportados e, geralmente, há um conjunto de metadados no banco de dados que determina quais arquivos são e quais estruturas de banco de dados estão neles. Se, ao criar cópias de backup de arquivos, você espera que outra instância do banco de dados possa utilizá-los, será necessário fazer um backup e salvar os metadados associados a ele, nos quais esse banco de dados depende, para que o backup seja portátil.

Ao criar um backup lógico, os dados são exportados do banco de dados para um formato que teoricamente pode ser transferido para qualquer sistema. Geralmente, os metadados também são salvos, mas provavelmente serão relevantes para o momento em que o backup foi realizado. Um exemplo é a exportação de todas as instruções de inserção necessárias para preencher um banco de dados vazio ao atualizá-lo. Outro exemplo é uma sequência JSON. Como resultado, os backups lógicos, em regra, levam muito tempo, porque essa não é uma operação física de cópia e gravação, mas a extração de dados linha por linha. Da mesma forma, a recuperação é acompanhada por toda a sobrecarga usual do banco de dados, como bloquear e criar logs de refazer e desfazer.

Um ótimo exemplo dessa separação é a distinção entre replicação baseada em linha e replicação baseada em instrução. Em muitos bancos de dados relacionais, a replicação baseada em agente significa que, após a gravação no sistema de controle de versão, um diário de operadores da linguagem de manipulação de dados (DML, ou inserir, atualizar, substituir, excluir) é adicionado a eles. Essas instruções são passadas para as réplicas nas quais são executadas. Outra abordagem para replicação é baseada em seqüências de caracteres ou no Change Data Capture (CDC).

Autônomo ou operacional?

Um backup offline (ou frio) é aquele em que a instância do banco de dados que usa os arquivos está desabilitada. Graças a isso, você pode copiar rapidamente arquivos sem se preocupar em manter o estado no momento, enquanto outros processos leem e gravam dados. Esta é uma condição ideal, mas muito rara.

Com um backup online (ou quente), você ainda copia todos os arquivos, mas há uma complexidade adicional associada à necessidade de obter uma captura instantânea consistente dos dados, que deve existir no momento em que o backup é executado. Além disso, se o tráfego atual acessar o banco de dados durante o backup, você deve ter cuidado para não exceder a taxa de transferência do subsistema de E / S no nível de armazenamento. Mesmo limitando a carga, você pode achar que os mecanismos usados para manter a consistência introduzem atrasos irracionais no aplicativo.

Completo, incremental e diferencial

Ter um backup completo, independentemente do método criado, significa que o conjunto de dados local é totalmente reservado. Para conjuntos de dados pequenos, isso é bastante comum. Para 10 TB, isso pode levar uma quantidade incrível de tempo.

Os backups diferenciais permitem fazer backup apenas dos dados que foram alterados desde o último backup completo. Mas, na prática, geralmente é feito backup de mais dados do que apenas os alterados, porque os dados são organizados na forma de estruturas de um determinado tamanho - páginas. O tamanho da página é, por exemplo, 16 ou 64 Kbytes, e a página contém muitas linhas de dados. Os backups diferenciais fazem backup de todas as páginas nas quais os dados foram alterados. Assim, com tamanhos de páginas grandes, são obtidos backups de um tamanho muito maior do que se apenas os dados modificados fossem armazenados lá.

Os backups incrementais são semelhantes aos backups diferenciais, exceto que a data do último backup ao qual os dados alterados se referem é incremental ou completa. Portanto, ao restaurar a partir de um backup incremental, pode ser necessário restaurar o último backup completo, bem como um ou mais backups incrementais, para chegar ao ponto atual.

Sabendo disso, discutiremos vários pontos que devem ser considerados ao escolher uma estratégia eficaz de backup e recuperação de dados.

Considerações sobre recuperação de dados

Ao escolher uma estratégia eficaz pela primeira vez, considere novamente suas metas de qualidade de serviço (SLOs), discutidas no Capítulo 2. Em particular, é necessário considerar os indicadores de disponibilidade e confiabilidade. Qualquer que seja a estratégia escolhida no final, ela ainda deve incluir a capacidade de recuperar dados dentro dos limites predefinidos de tempo de atividade. E você terá que fazer backup rapidamente para garantir a conformidade com suas especificações de confiabilidade.

Se você fizer backup todos os dias e manter os logs de transações entre os backups armazenados no nível do site, poderá facilmente perder essas transações até o próximo backup.

Além disso, você precisa considerar como o conjunto de dados funciona em um ecossistema holístico. Por exemplo, seus pedidos podem ser armazenados em um banco de dados relacional, onde tudo é corrigido na forma de transações e, portanto, é facilmente restaurado em relação a outros dados armazenados nesse banco de dados. No entanto, depois que a ordem é formada, o fluxo de trabalho pode ser acionado por um evento armazenado no sistema de filas ou armazenamento do tipo "valor-chave". Esses sistemas podem garantir a integridade dos dados apenas ocasionalmente ou brevemente (para ser efêmeros), referindo-se, se necessário, ao banco de dados relacional ou usando-o para recuperação. Como considerar esses fluxos de trabalho durante a recuperação?

Se você estiver lidando com um ambiente em que o desenvolvimento rápido está em andamento, pode ser que os dados armazenados no backup tenham sido gravados e usados por uma versão do aplicativo e, após a restauração, outro seja executado. Como o aplicativo irá interagir com dados desatualizados? Bem, se os dados forem versionados - isso poderá ser levado em consideração, mas você deve estar ciente dessa possibilidade e estar preparado para esses casos. Caso contrário, o aplicativo poderá danificar logicamente esses dados, o que levará a problemas ainda maiores no futuro.

Todas essas e muitas outras nuances que não podem ser previstas devem ser levadas em consideração ao planejar a recuperação de dados. Como afirmado no capítulo 3, é impossível se preparar para qualquer situação. Mas é muito importante tentar fazer isso. A recuperação de dados é um dos deveres mais importantes de um engenheiro para garantir a confiabilidade do banco de dados. Portanto, seu plano de recuperação de dados deve ser o mais amplo possível e levar em conta o maior número possível de problemas possíveis.

Cenários de recuperação

Tendo levado tudo em consideração, discutiremos os tipos de incidentes e operações que podem exigir recuperação de dados para que todas as necessidades possam ser planejadas. Primeiro, você pode dividir todos os cenários em planejados e não planejados. Considerando a recuperação de dados apenas como uma ferramenta para resolver emergências, você limitará as ferramentas da sua equipe apenas aos cuidados de emergência e simulará acidentes. Por outro lado, se a recuperação de dados for incluída nas atividades diárias, pode ser esperado um maior grau de conscientização e resolução bem-sucedida de emergências. Além disso, teremos mais dados para determinar se a estratégia de recuperação suporta nossos SLOs. Com algumas execuções diárias do script, será mais fácil obter um conjunto de amostras,que inclui valores-limite e que pode ser usado com bastante confiança no planejamento.

Cenários de recuperação agendada

Em quais tarefas diárias os processos de restauração podem ser integrados? Aqui está a lista que encontramos com mais frequência em sites diferentes:

a criação de novos nós e clusters em um ambiente de operação industrial;
criação de vários ambientes;
realização de extração, transformação e carregamento (Extração, Transformação e Carga, ETL) e estágios do processo tecnológico de processamento de dados para armazenamentos sequencialmente colocados;
teste de performance.

Ao executar essas operações, inclua o processo de recuperação na pilha de controle operacional. Considere os seguintes indicadores.

Tempo. Quanto tempo leva para concluir cada componente e todo o processo? Desembalando? Cópia de? Execução de log? Testando?
O tamanho. Quanto espaço um backup ocupa, compactado e descompactado?
. ?

Essas informações ajudarão a evitar problemas de largura de banda, o que ajudará a garantir a estabilidade do processo de recuperação.

Novos nós e clusters em um ambiente operacional industrial

Se seus bancos de dados fazem parte de uma infraestrutura imutável ou não, existem oportunidades para reconstruções regulares, nas quais os procedimentos de recuperação serão usados conforme necessário.

Os bancos de dados raramente são incluídos no dimensionamento automático de sistemas devido à quantidade de tempo que pode ser necessária para o carregamento inicial de um novo nó e sua colocação em um cluster. No entanto, não há motivos para impedir que a equipe crie um planejamento para adicionar regularmente novos nós ao cluster para testar esses processos. Macaco do Caos ( http://bit.ly/2zy1qsE) - uma ferramenta desenvolvida pela Netflix que desliga os sistemas aleatoriamente, permite que você faça isso de maneira a poder testar todo o processo de monitoramento, emissão de notificações, classificação e restauração. Se você ainda não o fez, pode incluí-lo no plano da lista de verificação de processos que seu departamento de operações deve executar em intervalos regulares para que todos os funcionários se familiarizem com o procedimento. Essas ações permitem testar não apenas a recuperação completa e incremental, mas também a inclusão da replicação e o processo de colocar o nó em operação.

Crie ambientes diferentes

Você inevitavelmente criará ambientes de desenvolvimento, integração e teste operacional para demonstração e outros fins. Alguns desses ambientes requerem recuperação total dos dados e precisam implementar a recuperação do nó e a recuperação total do cluster. Alguns ambientes têm outros requisitos, como suporte de recuperação parcial para teste de recursos e limpeza de dados para garantir a privacidade do usuário. Isso permite testar a recuperação de dados em um momento específico, bem como a recuperação de objetos específicos. Tudo isso é muito diferente da recuperação completa padrão e é útil para reparar danos causados por ações do operador e erros de aplicativos. Ao criar uma API,que fornecem recuperação de dados no nível da instalação e em um momento específico, você pode facilitar a automação e a familiarização dos funcionários com esses processos.

Processos de ETL e pipeline para data warehouses localizados mais abaixo no pipeline

Quanto às tarefas de construção de um ambiente, os processos e as APIs de recuperação a partir de snapshots ou no nível de objetos individuais podem ser aplicados com êxito ao transferir dados dos bancos de dados de produção para os pipelines para análise adicional e fluxo de armazenamento .

Teste de campo

Durante a execução de vários cenários de teste, você precisará de cópias dos dados. Alguns testes, por exemplo, capacidade e carga, exigem um conjunto completo de dados, o que é ótimo para recuperação completa. Os testes funcionais podem exigir conjuntos de dados menores, o que permitirá a recuperação em um momento específico e no nível da instalação.

O teste de recuperação de dados em si pode ser uma operação contínua. Além de usar processos de recuperação de dados em cenários cotidianos, você pode configurar operações de recuperação contínua. Isso automatizará o teste e a validação para identificar rapidamente quaisquer problemas que possam surgir se o processo de backup for interrompido. Quando se trata de implementar esse processo, muitos perguntam como verificar o sucesso de uma recuperação.

Ao criar um backup, você pode obter muitos dados que podem ser usados para teste, por exemplo:

O identificador mais recente na sequência de incremento automático
contador de linhas para objetos;
somas de verificação para subconjuntos de dados inseridos apenas e, portanto, podem ser considerados imutáveis;
somas de verificação nos arquivos de definição de esquema.

Como em qualquer teste, a abordagem deve ser multinível. Existem vários testes que terão êxito ou falharão rapidamente. Este deve ser o primeiro nível de teste. Os exemplos são comparar somas de verificação para definições de metadados / objetos, iniciar com êxito uma instância de banco de dados e conectar-se com êxito a um fluxo de replicação. Operações que podem levar mais tempo, como cálculo de somas de verificação e tabelas de contagem, devem ser executadas posteriormente durante a verificação.

Scripts não planejados

Levando em consideração todos os cenários planejados diários que podem ser usados, o processo de recuperação de dados deve ser bem depurado, documentado, elaborado e suficientemente livre de erros e problemas. Graças a isso, cenários não planejados raramente acabam sendo tão assustadores quanto poderiam ser. A equipe não deve ver a diferença entre recuperação planejada e não planejada. Listamos e consideramos em detalhes situações que podem exigir que realizemos processos de recuperação:

erro do usuário
erro de aplicação;
disponibilidade de serviços de infraestrutura;
erros de sistema operacional e erros de hardware;
falhas de hardware;
falhas no datacenter.

Erro do usuário Idealmente, erros do usuário raramente devem ocorrer. Ao construir uma “grade” e uma “barreira” para engenheiros, você pode evitar muitas dessas situações. No entanto, sempre existe a possibilidade de o operador causar danos acidentalmente. Um exemplo típico é a cláusula WHERE esquecida em todos os lugares ao executar UPDATE ou DELETE em um aplicativo cliente de banco de dados. Ou, por exemplo, a execução do script de limpeza de dados não está em um ambiente de teste, mas em um sistema de "produção" em funcionamento. Geralmente, a operação é executada corretamente, mas no momento errado ou não para esses hosts. Tudo isso está relacionado a erros do usuário. Muitas vezes, eles são identificados e corrigidos imediatamente. No entanto, algumas vezes as consequências de tais mudanças passam despercebidas por vários dias ou semanas.

Erros de aplicação

Erros de aplicativo são os piores cenários discutidos, pois podem ser muito traiçoeiros. Os aplicativos estão mudando constantemente a maneira como interagem com os data warehouses. Muitos aplicativos também gerenciam integridade referencial e ponteiros externos para recursos como arquivos ou identificadores de terceiros. É assustador imaginar o que acontecerá se você fizer uma alteração que estrague os dados, os exclua ou adicione dados incorretos de maneiras que possam passar despercebidas por algum tempo.

Serviços de infraestrutura

No capítulo 6, introduzimos a mágica dos serviços de gerenciamento de infraestrutura. Infelizmente, esses sistemas podem ser tão destrutivos quanto úteis, o que pode levar a consequências em larga escala relacionadas à edição de um arquivo, apontando para outro ambiente ou definições de configuração incorretas.

Erros de SO e erros de hardware

Os sistemas operacionais e equipamentos com os quais eles interagem também são sistemas criados por pessoas e, portanto, podem ocorrer erros neles que podem ter conseqüências inesperadas devido a configurações não documentadas ou pouco conhecidas. No contexto da recuperação de dados, isso é especialmente verdade no que diz respeito à maneira como os dados são transferidos do banco de dados via caches do SO para sistemas de arquivos, controladores e, eventualmente, para discos. Danos ou perda de dados acontecem com muito mais frequência do que pensamos. Infelizmente, nossa confiança e confiança nesses mecanismos gera a expectativa de integridade dos dados em vez de ceticismo quanto a isso.

Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?

. , , . , . — .

, ZFS, , . RAID-, , .

Falhas de

hardware Os componentes de hardware falham, em princípio, e em sistemas distribuídos isso acontece regularmente. Você encontra constantemente falhas de disco, memória, processador, controlador e dispositivo de rede. As consequências dessas falhas de hardware podem ser a falha de nós ou atrasos nos nós, o que torna o sistema inutilizável. Sistemas compartilhados, como dispositivos de rede, podem influenciar clusters inteiros, tornando-os inacessíveis ou dividindo-os em clusters menores que não sabem que a rede foi dividida. Isso pode levar a discrepâncias rápidas e significativas nos dados que precisam ser combinados e corrigidos.

Falhas no data center

Às vezes, problemas de hardware no nível da rede levam a falhas no data center. Acontece que a sobrecarga dos backplanes de armazenamento causa falhas em cascata, como foi o caso dos serviços web da Amazon em 2012 ( http://bit.ly/2zxSpzR ). Às vezes, furacões, terremotos e outros desastres levam à falha de centros de dados inteiros. A recuperação subsequente testará até mesmo as estratégias de recuperação mais confiáveis.

Escopo do script

Depois de enumerar os cenários planejados e não planejados que podem exigir recuperação, adicionamos mais uma dimensão a esses eventos para que nossa apresentação se torne volumosa. Isso será útil para escolher o método de resposta mais apropriado. Considere as seguintes opções:

falha localizada em um único nó;
falha de todo o cluster;
Uma falha que afeta todo o datacenter ou vários clusters.

No caso de uma falha local ou de site único, a recuperação é limitada a um host. Você pode adicionar um novo nó ao cluster para aumentar a capacidade ou substituir um nó com falha. Ou, o sistema implementa a atualização contínua e a restauração será realizada nó por nó. De qualquer forma, essa é uma recuperação local.

No nível do cluster, a necessidade de recuperação é global para todos os membros deste cluster. Talvez tenha havido uma alteração ou exclusão destrutiva de dados que se espalhou em cascata para todos os nós. Ou você precisa introduzir um novo cluster para testar a capacidade.

Se houve uma falha na escala do datacenter ou em vários clusters, significa que é necessário restaurar todos os dados no local de sua localização física ou em toda a área de falha. Isso pode ser devido a uma falha do data warehouse compartilhado ou a uma falha que causou uma falha catastrófica do data center. Essa recuperação também pode ser necessária durante a implantação planejada de um novo site secundário.

Além do escopo, há um escopo de conjunto de dados. Aqui você pode listar três opções possíveis:

um objeto;
vários objetos;
metadados do banco de dados.

Na escala de um objeto, apenas esse objeto específico requer recuperação de dados - alguns ou todos. O caso discutido anteriormente, como resultado do qual, quando a operação DELETE foi executada, mais dados foram excluídos do que o planejado, refere-se a uma falha no mesmo objeto. Se vários objetos falharem, vários ou, possivelmente, todos os objetos em um banco de dados específico serão afetados. Isso pode acontecer se o aplicativo estiver danificado, a atualização ou a migração do segmento falhar. Finalmente, há falhas na escala dos metadados do banco de dados quando tudo está em ordem com os dados armazenados no banco de dados, mas os metadados que o tornam utilizável são perdidos, como dados do usuário, privilégios de segurança ou conformidade com arquivos do SO.

Consequências do script

É importante não apenas identificar o cenário que requer recuperação e identificar a área de falha, mas também determinar as possíveis conseqüências, pois elas serão significativas na escolha de uma abordagem para recuperação. Se a perda de dados não afetar o SLO, você poderá escolher uma abordagem metódica e lenta que minimize a expansão das consequências. As mudanças mais globais que levam à interrupção do SLO devem ser abordadas com cautela, escolhendo uma recuperação rápida do serviço e somente depois passando para uma limpeza a longo prazo. Todas as abordagens podem ser divididas nas três categorias a seguir.

O impacto no SLO, falha do aplicativo, afetou a maioria dos usuários.
Ameaça SLO, alguns usuários sofreram.
As funções que não ameaçam o SLO são afetadas.

Sobre os autores

Campbell Lane (Laine Campbell) é gerente sênior (diretor sênior) da empresa de design Fastly. Ela também foi a fundadora e CEO do PalominoDB / Blackbird, um serviço de consultoria que atende bancos de dados de várias empresas, incluindo Obama for America, Activision Call of Duty, Adobe Echosign, Technorati, Livejournal e Zendesk. Ela tem 18 anos de experiência na operação de bancos de dados e sistemas distribuídos escaláveis.

Cherity Majors(Charity Majors) é o CEO e co-fundador da honeycomb.io. Combinando a precisão dos agregadores de logs, as métricas de velocidade das séries temporais e a flexibilidade das métricas de desempenho de aplicativos (APMs), o honeycomb é o primeiro serviço analítico de nova geração do mundo. Antes, Cheriti era especialista em operações do Parse / Facebook, gerenciando uma enorme frota de conjuntos de réplicas do MongoDB, além de Redis, Cassandra e MySQL. Ela também trabalhou em estreita colaboração com a equipe do RocksDB no Facebook, participando do desenvolvimento e implantação da primeira instalação do Mongo + Rocks do mundo usando a API de plug-in de armazenamento.

»Mais informações sobre o livro podem ser encontradas no site do editor
» Conteúdo
» Trecho

Para Khabrozhiteley, desconto de 25% no cupom - Bases de dados

Após o pagamento da versão em papel do livro, um livro eletrônico é enviado por e-mail.

Livro “Bancos de dados. Engenharia de Confiabilidade