Beyond Linux® From Scratch (Edição systemd ) - Versão 12.0

Capítulo 22. Bases de Dados

Observações Importantes Relativas a Atualização do Logiciário do Servidor de Base de Dados

[Nota]

Nota

Esta seção é sobre reinstalar logiciário de base de dados quando uma base de dados existente estiver em uso. Ela não é aplicável para instalações iniciais ou se não existir base de dados para o pacote sendo atualizado, mas os(as) usuários(as) deveriam lê-la para ficarem cientes dos problemas que podem surgir no futuro.

Vamos começar este capítulo com uma captura de tela dramática de um erro que realmente aconteceu. Este erro não ocorrerá se você estiver instalando o logiciário de base de dados pela primeira vez: 

$ sudo systemctl status postgresql
-- postgresql.service - PostgreSQL database server
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2021-10-26 17:11:53 CDT; 2min 49s ago
    Process: 17336 ExecStart=/usr/bin/pg_ctl -s -D ${PGROOT}/data start -w -t 120 (code=exited, status=1/FAILURE)
         CPU: 7ms

Oct 26 17:11:53 SVRNAME systemd[1]: Starting PostgreSQL database server...
Oct 26 17:11:53 SRVNAME postgres[17338]: 2021-10-26 17:11:53.420 CDT [17338] FATAL:
                database files are incompatible with server
Oct 26 17:11:53 SRVNAME postgres[17338]: 2021-10-26 17:11:53.420 CDT [17338] DETAIL:
                The data directory was initialized by PostgreSQL version 13,
                which is not compatible with this version 14.0.
Oct 26 17:11:53 SRVNAME postgres[17336]: pg_ctl: could not start server
Oct 26 17:11:53 SRVNAME postgres[17336]: Examine the log output.
Oct 26 17:11:53 SRVNAME systemd[1]: postgresql.service: Control process exited, code=exited, status=1/FAILURE
Oct 26 17:11:53 SRVNAME systemd[1]: postgresql.service: Failed with result 'exit-code'.
Oct 26 17:11:53 SRVNAME systemd[1]: Failed to start PostgreSQL database server.

Para evitar situações como essa (ou seja, o teu logiciário do servidor de base de dados se recusa a iniciar), leia a discussão a seguir relativa a melhor maneira de atualizar um Sistema de Gerenciamento de Base de Dados (SGBD).

A causa raiz do erro mostrado acima foi uma atualização do logiciário do servidor para uma versão principal mais recente que deixou os arquivos de dados intactos. Nesse caso, o(a) administrador(a) conseguiu recuperar o SGBD sem qualquer perda de dados.

Mesmo se você estiver fazendo uma instalação inicial do SGBD, leia esta seção. Ela fornece informações relativas a implementação de procedimentos de cópia de segurança e restauração (ou pelo menos uma estratégia para criá-las) que irão satisfazer as tuas necessidades e garantir a segurança dos teus dados.

Atualização de Pacotes do Servidor de Base de Dados

Os sistemas de base de dados funcionam em arquivos que contém os metadados da base de dados e os próprios dados. A estrutura interna desses arquivos é otimizada para uso pelo logiciário do servidor. Quando esse logiciário de servidor for atualizado, o novo logiciário poderá utilizar um formato de arquivo diferente do usado anteriormente. Às vezes, o novo logiciário pode funcionar tanto com o formato antigo quanto com o novo‐mas sem as melhorias de desempenho que o novo formato oferece. Outras vezes, o novo logiciário de servidor reformatará os arquivos de dados automaticamente após a atualização.

Infelizmente, o caso mais provável é o de que o novo logiciário de servidor reclame dos formatos desatualizados de arquivos e saia. Quando isso acontece e você sobrescreveu o antigo logiciário do servidor, você possivelmente acabe com um sistema quebrado e perda de dados.

As mudanças nos formatos dos arquivos de dados geralmente ocorrem em mudanças da versão principal, mas também podem ocorrer em outros momentos. Antes de atualizar qualquer logiciário de SGBD, verifique a documentação para ver se essa atualização faz mudanças que exigem reformatar a base de dados.

Claro, se você tiver bases de dados com conteúdo que não seja reconstruível facilmente, [então] é sempre uma boa ideia criar cópias de segurança da base de dados de tempos em tempos. Antes de atualizar o logiciário do servidor, você deveria executar outra cópia de segurança.

Atualização por Cópia de Segurança e Restauração

[Nota]

Nota

Uma cópia de segurança é inútil se não existir um processo verificado para restaurar os dados a partir dessa cópia de segurança. Ao executar um servidor de base de dados, você não deveria somente criar cópias de segurança; você também deveria verificar se o processo de restauração realmente funciona. O momento de testar o procedimento de restauração é antes de você precisar recuperar urgentemente os dados perdidos.

A maioria dos logiciários de servidor de base de dados fornece algumas ferramentas básicas para criar cópias de segurança dos dados deles. Normalmente, as cópias de segurança criadas com essas ferramentas conseguem ser lidas por versões mais recentes do logiciário (por meio de uma ferramenta de restauração). Usar ferramentas mais antigas de restauração com dados de cópia de segurança mais recentes é uma má ideia; você nunca deveria assumir cegamente que isso funcionará. Pode ser, mas geralmente não.

A maneira mais fácil de atualizar teus arquivos de base de dados é a de

  • Criar uma cópia completa de segurança da base de dados usando as ferramentas antigas.

    Essa etapa cria uma cópia fora de linha dos arquivos da base de dados—para arquivamento de longo prazo, para recuperação de desastres ou como preparação para uma atualização. Essa cópia de segurança fora de linha consiste ou em (1) uma cópia completa um-para-um dos arquivos atuais da base de dados ou (2) uma cópia completa de segurança dos arquivos da base de dados a partir de um determinado ponto no tempo, além de todos os dados do diário (ou seja, na terminologia da "Oracle®", é chamado de "Arquivamento Contínuo" ou "write ahead log" ("WAL") no "Postgresql") descrevendo as mudanças feitas depois desse ponto no tempo. Essa segunda forma leva menos tempo para ser criada (se o logiciário da Base de Dados fornecer esse tipo de registro em diário) porque você tem de salvar somente os dados que foram mudados desde quando a cópia completa de segurança mais recente foi criada.

    Ao atualizar o logiciário do servidor de base de dados, uma cópia completa de segurança (que pode ser usada para cópias incrementais de segurança subsequentes) deveria ser criada; mas se existirem muitos dados, [então] uma cópia incremental de segurança será suficiente. A melhor estratégia para você depende da quantidade de dados armazenados em tua base de dados (são algumas centenas de linhas da tabela ou centenas de terabytes?). Uma cópia completa de segurança nesse último caso não pode ser feita rapidamente. Para proteger totalmente teus dados, crie uma cópia de segurança dos aplicativos antigos (e(ou) dos fontes deles) e salve-a, junto com os arquivos de dados, para ter certeza de que existe uma solução alternativa caso o novo logiciário não consiga ler os dados antigos.

  • Atualizar o logiciário do servidor

    Nessa etapa, as instruções para construir o logiciário do servidor de base de dados são executadas exatamente como são mostradas nas seções subsequentes falando sobre "GBDs" como "MariaDB" ou "Postgresql". Ou seja, construa o logiciário normalmente usando as instruções do BLFS.

  • Restaurar a base de dados usando as novas ferramentas.

    Para restaurar os dados, as ferramentas do logiciário de servidor recém-instalado deveriam ser usadas. Durante o processo de restauração, as novas ferramentas criarão e (ou) atualizarão os arquivos de dados no formato que o novo logiciário exige. Supõe-se que o logiciário mais recente seja capaz de ler os dados antigos.

Como você já tem um procedimento de cópia de segurança em vigor (e testou teu procedimento de restauração, certo?), essa pode ser a maneira mais fácil de atualizar, pois você pode usar teus processos bem conhecidos para atualizar como sempre faz—pelo menos em termos de cópia de segurança e de restauração.

Atualização dos Arquivos da Base de Dados Usando Ferramentas do Sistema

Alguns sistemas de base de dados (por exemplo, o "Postgresql") fornecem uma ferramenta que pode reformatar (atualizar) os arquivos existentes de base de dados para o novo formato. Se precisar restaurar a partir de uma cópia de segurança (por exemplo, executar a ferramenta de atualização falhou), [então] você terá que reinstalar o logiciário antigo para recuperar os teus dados.

Mesmo que as ferramentas de reformatação funcionem conforme anunciado, você deveria criar uma cópia completa de segurança antes de executá-las. Uma falha poderia causar sérios danos à base de dados.

Observações para SGBDs Específicos

PostgreSQL

Documentação do(a) desenvolvedor(a) para Cópia de Segurança/Restauração: https://www.postgresql.org/docs/current/backup.html

MariaDB

Documentação do(a) desenvolvedor(a) para Cópia de Segurança/Restauração: https://mariadb.com/kb/en/backup-and-restore-overview/

Sqlite

Não subestime o "Sqlite". Ele é um SGBD rico em recursos. A principal diferença para os dois grandes concorrentes acima é a de que o "SQLite" não fornece acesso por meio de uma "API" de rede de intercomunicação. As bases de dados "SQLite" são sempre armazenadas na máquina que executa o aplicativo que usa a base de dados. A manipulação do conteúdo dos dados é feita por meio de chamadas de "API" para funções de biblioteca diretamente no aplicativo.

Na documentação do(a) desenvolvedor(a) você possivelmente ache o seguinte útil:

Documentação da ferramenta de linha de comando "sqlite3": https://www.sqlite.org/cli.html

Documentação de chamadas da "API" de cópia de segurança: https://www.sqlite.org/backup.html

Infelizmente, não existe nenhum capítulo dedicado na documentação do(a) desenvolvedor(a) falando a respeito de cópia de segurança/restauração, mas existem vários artigos referentes a isso na Internet. Aqui está um exemplo.

Documentação para Cópia de Segurança/Restauração: https://database.guide/backup-sqlite-database/

Base de Dados Berkeley

Assim como o Sqlite, esse logiciário atua em arquivos locais de base de dados; não existe interface de rede de intercomunicação.

Os recursos relevantes para produzir cópia de segurança/restaurar uma base de dados Berkeley são as páginas de manual de "db_dump" e a contraparte dele "db_load".