Documentação do PostgreSQL 8.0.0 | ||||
---|---|---|---|---|
Anterior | Início | Capítulo 16. Ambiente do servidor em tempo de execução | Fim | Próxima |
Antes que os usuários possam acessar o banco de dados, o servidor de banco de dados deve ser colocado em execução. O programa servidor de banco de dados chama-se postmaster. O postmaster precisa saber onde se encontram os dados a serem utilizados. Isto é feito através da opção -D. Portanto, a maneira mais simples de colocar o servidor em execução é usando
$ postmaster -D /usr/local/pgsql/data
que deixa o servidor processando em primeiro plano. Deve ser executado conectado à conta de usuário do PostgreSQL. Sem a opção -D o servidor tenta utilizar o diretório de dados especificado na variável de ambiente PGDATA. Se esta variável também não existir, então a inicialização falha.
Normalmente é melhor executar o postmaster em segundo plano, e neste caso a sintaxe usual para o interpretador de comandos é:
$ postmaster -D /usr/local/pgsql/data >arquivo_de_log 2>&1 &
É importante armazenar as saídas stdout e stderr do servidor em algum lugar, conforme mostrado acima. Isto é útil para fins de auditoria e para diagnosticar problemas (A Seção 21.3 contém uma explicação mais detalhada sobre o manuseio do arquivo de log).
O postmaster também aceita várias outras opções de linha de comando. Para obter informações adicionais deve ser consultada a página de referência do postmaster e a Seção 16.4 abaixo.
A sintaxe do interpretador de comandos pode se tornar entediante em pouco tempo. Por isso é fornecido o programa pg_ctl para simplificar algumas tarefas. Por exemplo,
pg_ctl start -l arquivo_de_log
inicializa o servidor em segundo plano, e envia a saída para o arquivo de log especificado. A opção -D possui o mesmo significado para este programa que no postmaster. O programa pg_ctl também pode parar o servidor.
Normalmente se quer que o servidor de banco de dados seja inicializado quando o computador é ligado. Os scripts de auto-inicialização são específicos de cada sistema operacional. Existem alguns scripts distribuídos junto com o PostgreSQL no diretório contrib/start-scripts. Para instalar estes scripts é necessário o privilégio de root.
Sistemas diferentes possuem convenções diferentes para inicializar processos durante a inicialização do sistema operacional. Muitos sistemas possuem o arquivo /etc/rc.local ou /etc/rc.d/rc.local. Outros utilizam diretórios rc.d. Seja da maneira que for, o servidor deve executar sob a conta de usuário do PostgreSQL, e não sob root ou qualquer outro usuário. Portanto, os comandos provavelmente devem ser construídos utilizando su -c '...' postgres. Por exemplo:
su -c 'pg_ctl start -D /usr/local/pgsql/data -l arquivo_de_log' postgres
Abaixo são mostradas algumas sugestões mais específicas para vários sistemas operacionais (Os valores genéricos devem ser sempre substituídos pelo diretório de instalação e nome de usuário apropriados para cada caso).
No FreeBSD deve ser visto o arquivo contrib/start-scripts/freebsd na distribuição do código fonte do PostgreSQL.
No OpenBSD devem ser adicionadas as seguintes linhas ao arquivo /etc/rc.local:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postmaster ]; then su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/arquivo_de_log -s' postgres echo -n ' postgresql' fi
Nos sistemas Linux deve ser adicionado
/usr/local/pgsql/bin/pg_ctl start -l arquivo_de_log -D /usr/local/pgsql/data
ao arquivo /etc/rc.d/rc.local, ou ser visto o arquivo contrib/start-scripts/linux na distribuição do código fonte do PostgreSQL.
No NetBSD deve ser utilizado o script de inicialização do FreeBSD ou do Linux, conforme se preferir.
No Solaris deve ser criado um arquivo chamado /etc/init.d/postgresql contendo a seguinte linha:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l arquivo_de_log -D /usr/local/pgsql/data"
Depois deve ser criado um vínculo simbólico para este arquivo em /etc/rc3.d como S99postgresql.
Enquanto o postmaster está executando, seu identificador de processo (PID) fica armazenado no arquivo postmaster.pid no diretório de dados. Este arquivo é utilizado para impedir que mais de um processo postmaster execute usando o mesmo diretório de dados. Também pode ser utilizado para parar o processo postmaster.
Existem vários motivos triviais pelos quais a inicialização do servidor pode não ser bem-sucedida. Deve ser visto o arquivo de log do servidor, ou deve ser feita a inicialização manual do servidor (sem redirecionar a saída padrão ou o erro padrão) para ver as mensagens de erro mostradas. Abaixo são explicadas detalhadamente algumas das mensagens de erro mais comuns.
LOG: could not bind IPv4 socket: Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. FATAL: could not create TCP/IP listen socket -- Tradução da mensagem LOG: não foi possível vincular soquete IPv4: Endereço já sendo usado DICA: Há outro postmaster usando a porta 5432? Se não houver, aguarde uns poucos segundos e tente novamente. FATAL: não foi possível criar soquete TCP/IP de atendimento
Normalmente esta mensagem significa o que sugere: tentou-se inicializar um postmaster na mesma porta que outro já estava usando. Entretanto, se o núcleo da mensagem de erro não for Endereço já sendo usado (Address already in use), ou alguma variação desta, pode estar ocorrendo um problema diferente. Por exemplo, tentar inicializar o postmaster em um número de porta reservado pode levar a algo como:
$ postmaster -p 666 LOG: could not bind IPv4 socket: Permission denied HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry. FATAL: could not create TCP/IP listen socket -- Tradução da mensagem LOG: não foi possível vincular soquete IPv4: Permissão negada DICA: Há outro postmaster usando a porta 666? Se não houver, aguarde uns poucos segundos e tente novamente. FATAL: não foi possível criar soquete TCP/IP de atendimento
Uma mensagem como
FATAL: could not create shared memory segment: Invalid argument DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600). -- Tradução da mensagem FATAL: não foi possível criar o segmento de memória compartilhada: Argumento inválido DETALHE: A chamada de sistema que falhou foi shmget(chave=5440001, tamanho=4011376640, 03600).
provavelmente significa que o limite para o tamanho da memória compartilhada do núcleo (kernel) é menor que a área de trabalho que o PostgreSQL está tentando criar (4011376640 bytes neste exemplo). Pode significar, também, que o núcleo não está configurado para dar suporte a memória compartilhada no estilo System-V. Como recurso temporário pode-se tentar inicializar o servidor com um número de buffers menor que o número normal (sinalizador -B). Mais tarde poderá ser necessário reconfigurar o núcleo para aumentar o tamanho de memória compartilhada permitido. Esta mensagem também pode ser vista quando se tenta inicializar vários servidores na mesma máquina, quando o espaço total requisitado excede o limite do núcleo.
Um erro como
FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(5440126, 17, 03600). -- Tradução da mensagem FATAL: não foi possível criar semáforos: Não há espaço suficiente na unidade DETALHE: A chamada de sistema que falhou foi semget(5440126, 17, 03600).
não significa que o espaço em disco está esgotado. Significa que o limite do núcleo para o número de semáforos System V é menor que o número de semáforos que o PostgreSQL deseja criar. Como acima, este problema pode ser evitado inicializando o servidor com um número reduzido de conexões permitidas (sinalizador -N), e posteriormente aumentado o limite do núcleo.
Caso ocorra a mensagem de erro "chamada de sistema ilegal", é provável que o núcleo não tenha suporte para memória compartilhada ou semáforos. Neste caso, a única opção é reconfigurar o núcleo para ativar estas funcionalidades.
Na Seção 16.5.1 são mostrados detalhes sobre a configuração das facilidades de IPC do System V .
Embora as condições de erro possíveis no lado cliente sejam bastante variadas e dependentes do aplicativo, algumas delas podem estar diretamente relacionadas com a maneira como o servidor é inicializado. Outras condições diferentes das mostradas abaixo devem estar documentadas no próprio aplicativo cliente.
psql: could not connect to server: Connection refused Is the server running on host "server.joel.com" and accepting TCP/IP connections on port 5432? -- Tradução da mensagem psql: não foi possível conectar com o servidor. Conexão recusada O servidor estão executando no hospedeiro "server.joel.com" e aceitando conexões TCP/IP na porta 5432?
Esta é uma falha genérica dizendo "Eu não pude encontrar o servidor para me comunicar". Parece com a mensagem mostrada acima quando se tenta uma comunicação TCP/IP. Um engano comum é esquecer de configurar o servidor para aceitar conexões TCP/IP.
Outra possibilidade é receber esta mensagem de erro ao se tentar uma comunicação através do soquete do domínio Unix com o servidor local:
psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? -- Tradução da mensagem psql: não foi possível conectar com o servidor. Arquivo ou diretório inexistente O servidor está executando localmente e aceitando conexões no soquete do domínio Unix "/tmp/.s.PGSQL.5432"?
A última linha é útil para verificar se o cliente está tentando se conectar ao local correto. Se existir realmente um servidor executando neste local, o núcleo da mensagem de erro será normalmente Conexão recusada (Connection refused) ou Arquivo ou diretório inexistente (No such file or directory), como mostrado (É importante perceber que neste contexto Conexão recusada não significa que o servidor recebeu o pedido de conexão e o recusou. Este caso produz uma mensagem diferente, conforme mostrado na Seção 19.3). Outras mensagens de erro, como Tempo de conexão esgotado, podem indicar problemas mais básicos, como falta de conectividade da rede.