18.2. Criação do agrupamento de bancos de dados #

18.2.1. Uso de sistemas de arquivos secundários
18.2.2. Sistemas de arquivos

Antes que se possa fazer qualquer coisa, deve ser inicializada uma área de armazenamento de bancos de dados no disco. Esta área é chamada de agrupamento de bancos de dados (database cluster). O padrão SQL usa o termo agrupamento de catálogos (catalog cluster). Um agrupamento de bancos de dados é uma coleção de bancos de dados gerenciados por uma única instância de um servidor de banco de dados em execução. Após a inicialização, o agrupamento de bancos de dados contém um banco de dados chamado postgres, o banco de dados padrão para uso por utilitários, usuários e aplicações de terceiros. O próprio servidor de banco de dados não requer que o banco de dados postgres exista, mas muitos programas utilitários externos assumem que ele existe. Durante a inicialização, são criados mais dois bancos de dados em cada instância, chamados template1 e template0. Como os nomes sugerem, serão usados ​​como modelos para bancos de dados criados posteriormente; eles não devem ser usados ​​para trabalho. (Veja Gerenciamento de bancos de dados para obter informações sobre como criar novos bancos de dados em uma instância.)

Em termos de sistema de arquivos, um agrupamento de bancos de dados é um único diretório onde todos os dados são armazenados. Chamamos isto de diretório de dados, ou área de dados. Cabe a você decidir onde armazenar os dados. Não há padrão, embora locais como /usr/local/pgsql/data e /var/lib/pgsql/data sejam populares. O diretório de dados deve ser inicializado antes de ser utilizado, usando o programa initdb instalado com o PostgreSQL.

Se estiver sendo usada uma versão pré-empacotada do PostgreSQL, esta versão poderá ter uma convenção específica sobre onde colocar o diretório de dados e, também, poderá fornecer um script para criar o diretório de dados. Neste caso, deve ser usado este script, em vez de executar o initdb diretamente. Veja a documentação do pacote para obter detalhes.

Para inicializar o agrupamento de banco de dados manualmente, deve ser executado o programa initdb, especificando o local do sistema de arquivos desejado para o agrupamento de bancos de dados com a opção -D. Por exemplo:

$ initdb -D /usr/local/pgsql/data

Note que este programa deve ser executado estando conectado à conta do usuário PostgreSQL, descrita na seção anterior.

Dica

Como alternativa à opção -D, pode ser definida a variável de ambiente PGDATA.

Também é possível executar o initdb através do programa pg_ctl, como:

$ pg_ctl -D /usr/local/pgsql/data initdb

Esta forma poderá ser mais intuitiva, se estiver sendo usado o comando pg_ctl para iniciar e parar o servidor (veja Ativação do servidor de banco de dados), de tal forma que o pg_ctl seja o único comando usado para gerenciar a instância do servidor de banco de dados.

O initdb tenta criar o diretório especificado, se este ainda não existir. Obviamente, vai falhar se o initdb não tiver permissões para escrever no diretório pai. Geralmente, é recomendável que o usuário do PostgreSQL seja dono não apenas do diretório de dados, mas também de seu diretório pai, para que isto não seja um problema. Se o diretório pai desejado também não existir, é necessário criá-lo primeiro, usando os privilégios de root, se o diretório avô não for gravável. Então o processo pode ficar assim:

root# mkdir /usr/local/pgsql
root# chown postgres /usr/local/pgsql
root# su postgres
postgres$ initdb -D /usr/local/pgsql/data

O initdb irá se recusar a executar se o diretório de dados existir e já tiver arquivos; é assim para evitar a substituição acidental de uma instalação existente.

Como o diretório de dados contém todos os dados armazenados nos bancos de dados, é essencial ser protegido contra acesso não autorizado. O initdb, portanto, revoga as permissões de acesso de todos os usuários, exceto as do usuário PostgreSQL e, opcionalmente, de grupo também. O acesso para grupo, quando ativado, é de leitura apenas, permitindo que um usuário sem privilégios, no mesmo grupo que o dono do agrupamento, faça uma cópia de segurança dos dados do agrupamento, ou execute outras operações que requerem apenas acesso de leitura.

Note que ativar ou desativar o acesso de grupo a um agrupamento de bancos de dados existente, requer que o agrupamento seja parado, e que seja definido o modo apropriado em todos os diretórios e arquivos antes de reiniciar o PostgreSQL. Caso contrário, poderá existir uma combinação de modos diferentes no diretório de dados. Para agrupamentos que permitem acesso apenas pelo dono, os modos apropriados são: 0700 para os diretórios, e 0600 para os arquivos. Para agrupamento que também permitem leituras pelo grupo, os modos apropriados são: 0750 para os diretórios, e 0640 para os arquivos.

Entretanto, embora o conteúdo do diretório seja seguro, a configuração padrão de autenticação do cliente permite que qualquer usuário local se conecte ao banco de dados, e até mesmo se torne o superusuário do banco de dados. Se os demais usuários locais não forem confiáveis, é recomendado usar uma das opções -W, --pwprompt, ou --pwfile, no initdb, para atribuir uma senha ao superusuário do banco de dados. Também, especificar -A scram-sha-256, para que o modo de autenticação padrão trust não seja usado; ou modificar o arquivo pg_hba.conf gerado após executar o initdb, mas antes de iniciar o servidor pela primeira vez. (Outras abordagens razoáveis incluem o uso da autenticação peer, ou permissões do sistema de arquivos para restringir as conexões. Veja Autenticação de cliente para obter mais informações.)

O initdb também inicializa a localidade padrão para o agrupamento de banco de dados. Normalmente, o initdb apenas pega as configurações de localidade do ambiente, e as aplica ao banco de dados sendo inicializado. É possível especificar uma localidade diferente para o banco de dados; mais informações sobre este assunto podem ser encontradas em Suporte a localidade. A ordem de classificação usada por padrão para o agrupamento de bancos de dados é definida pelo initdb e, embora seja possível criar bancos de dados usando uma ordem de classificação diferente, a ordem usada nos bancos de dados modelo que o initdb cria não pode ser alterada sem que estes sejam excluídos e recriados. Também ocorre um impacto no desempenho gerado pelo uso de localidades diferentes de C ou POSIX. Portanto, é importante fazer esta escolha corretamente da primeira vez.

O initdb também define a codificação do conjunto de caracteres padrão para o agrupamento de bancos de dados. Normalmente, deve ser escolhido para corresponder com a configuração de localidade. Para obter detalhes veja Suporte a conjunto de caracteres.

Localidades diferentes de C e POSIX dependem da biblioteca de ordenação do sistema operacional para a ordenação do conjunto de caracteres. A localidade controla a ordenação das chaves armazenadas nos índices. Por este motivo, um agrupamento não pode alternar para uma versão de biblioteca de ordenação incompatível, seja por meio de recuperação de instantâneo, replicação binária por fluxo, um sistema operacional diferente, ou por uma atualização do sistema operacional.

18.2.1. Uso de sistemas de arquivos secundários #

Muitas instalações criam seus agrupamentos de banco de dados em sistemas de arquivos (volumes) diferentes do volume raiz (root) da máquina. Se optar por fazer isto, não é recomendável tentar usar o diretório mais alto do volume secundário (ponto de montagem) como o diretório de dados. A melhor prática é criar um diretório dentro do diretório do ponto de montagem pertencente ao usuário do PostgreSQL e, em seguida, criar o diretório de dados dentro dele, evitando problemas de permissão, principalmente em operações como pg_upgrade, e também garante falhas limpas se o volume secundário for desmontado.

18.2.2. Sistemas de arquivos #

Geralmente, qualquer sistema de arquivos com semântica POSIX pode ser usado para o PostgreSQL. Os usuários preferem sistemas de arquivos diferentes por vários motivos, incluindo suporte do fornecedor, desempenho e familiaridade. A experiência indica que, todas as outras coisas sendo iguais, não se deve esperar grandes mudanças de desempenho ou comportamento meramente por alternar sistemas de arquivos, ou fazer pequenas alterações na configuração do sistema de arquivos.

18.2.2.1. NFS #

É possível usar um sistema de arquivos NFS para armazenar o diretório de dados do PostgreSQL. O PostgreSQL não faz nada de especial para sistemas de arquivos NFS, significando que assume que o NFS se comporta exatamente como as unidades conectadas localmente. O PostgreSQL não usa nenhuma funcionalidade conhecida por ter comportamento fora do padrão no NFS, como bloqueio de arquivo.

O único requisito obrigatório para usar o NFS com o PostgreSQL, é que o sistema de arquivos seja montado usando a opção hard. Com a opção hard, os processos podem travar indefinidamente se houver problemas de rede, portanto, esta configuração exige uma configuração de monitoramento cuidadosa. A opção soft interrompe as chamadas do sistema em caso de problemas de rede, mas o PostgreSQL não repete as chamadas do sistema interrompidas dessa maneira, portanto, qualquer interrupção resulta em erro de E/S sendo relatado.

Não é necessário usar a opção de montagem sync. O comportamento da opção async é suficiente, porque o PostgreSQL gera chamadas fsync em momentos apropriados para descarregar os caches de escrita. (é análogo ao modo como funciona em um sistema de arquivos local.) Entretanto, é altamente recomendável usar a opção de exportação sync no servidor NFS em sistemas onde ela existe (principalmente no Linux). Caso contrário, não há garantia de que o fsync, ou equivalente, no cliente NFS, atinja o armazenamento permanente no servidor, o que pode causar corrupção semelhante à execução com o parâmetro fsync desligado. Os valores padrão dessas opções de montagem e exportação diferem entre fornecedores e versões, portanto, se recomenda que sejam verificados, e talvez especificados explicitamente, para evitar qualquer ambiguidade.

Em alguns casos, um produto de armazenamento externo pode ser acessado via NFS, ou um protocolo de nível inferior, como o iSCSI. Neste último caso, o armazenamento aparece como um dispositivo de bloco, e qualquer sistema de arquivos disponível pode ser criado nele. Esta abordagem pode aliviar o DBA de ter que lidar com algumas das idiossincrasias do NFS, mas é claro que a complexidade do gerenciamento de armazenamento remoto acontece em outros níveis.