Não tenho certeza em que tipo de plataforma a AWS executa o 9.x Postgres. Qual é o valor máximo para o pid do processo?
Estou olhando para um problema em torno do uso de pg_backend_pidem um gatilho.
Alguns meses atrás, atualizei uma configuração do MySQL de 5.5 para 5.6. Desde então, tenho tido problemas com um script que uso para despejar os vários bancos de dados para poder fazer backup deles.
O script é um pequeno pedaço de perl que obtém uma lista de todos os bancos de dados e, em seguida, chama mysqldumpcada um da seguinte maneira:
mysqldump -udb_account -pdb_pw -hserver.com --single-transaction --flush-logs
--routines --triggers --quick $fn 2> $fn.err | gzip > $fn.mysql.gz
Problema: muitos desses bancos de dados têm centenas de tabelas (sempre aumentando). Para esses dbs maiores, o mysqldumpcomando geralmente sai após apenas uma única tabela. Se eu executar o comando de uma sessão de terminal, ele será executado corretamente. (normalmente é executado como um cron job 1x/wk)
O .errarquivo não contém mensagens. Nem o server.errarquivo no diretório raiz do MySQL.
Nota: este script estava funcionando bem no MySQL 5.5 por vários anos. Esse problema começou a acontecer quando atualizei para 5.6.
Além disso: a --flush-logsporção não está funcionando. A pasta mysql_bin nunca foi esvaziada desde que este sistema foi colocado online.
Uma variável que ainda não controlei: quando executado como um trabalho CRON, o script bifurca 3 processos por vez. Quando testo o comando em uma sessão de período, estou fazendo apenas um de cada vez.
Sistema em questão:
- CentOS 6.4
- x64
- RAM de 64 GB
Comecei a ver alguns erros estranhos de processos dependentes esta manhã. Após algumas pesquisas, parece que o arquivo /mysql/proc.MYD está configurado para comprimento zero. O arquivo /mysql/db.MYD parece estar truncado também.
O que é ainda mais interessante é que esse não é o caso do escravo replicado.
- O que causaria isso?
- Por que não apareceria no servidor escravo?
- Se eu copiar os arquivos /mysql/proc* do escravo de volta para o mestre - isso restaurará os procedimentos?
Quase todos os arquivos na pasta /mysql foram tocados ao mesmo tempo. Alguns foram alterados, enquanto muitos não foram. Meu primeiro pensamento é que é uma falha no sistema de arquivos, mas parece estar localizada nesta pasta.
EDIT: Detalhes pertinentes:
RHEL 5.x
MySQL 5.5
Desativei as duas instâncias do MySQL e estou tentando tirar a pasta MySQL da fita. Eu executaria fsck no volume, mas a página do manual tem alguns avisos bastante assustadores.