Eu tenho um script de shell bash que despeja todos os meus bancos de dados postgres do docker:
function dump_postgres {
mkdir -p ${BACKUP_DIR}/postgres/
docker ps -a --format '{{.Names}}\t{{.Ports}}' | grep 5432/tcp | awk '{ print $1 }' | while read -r line; do
echo "extracting database from container '${line}'"
docker exec -t ${line} pg_dumpall -v --lock-wait-timeout=600 -c -U postgres > ${BACKUP_DIR}/postgres/${line}.sql
done
}
dump_postgres >> "${LOG}" 2>> "${ERROR}"
O script descobre quais contêineres do Docker estão atendendo na porta postgres padrão e copia o banco de dados no formato sql.
O meu problema é que este comando pára de repente todos os dias quando iniciado pelo cron. Apenas pára e o contêiner que faz o dump não sai. Também não há saída no stderr.
Você tem alguma ideia de como resolver isso?
EDITAR:
o crontab se parece com isso:
30 1 * * * /home/mrbackup/backup.sh
o trabalho é agendado todas as noites às 1:30. Um script de monitoramento às 3:00 já vê que o backup falhou e o pg_dumpall está interrompido.
EDIT2:
Quassel esta noite é o problema, mas isso muda a cada dois dias. O nextcloud também causa problemas.
mais algumas informações sobre os processos:
# ps -efH
root 493 1 0 Mai24 ? 00:00:04 /usr/sbin/cron -f
root 12401 493 0 01:30 ? 00:00:00 /usr/sbin/CRON -f
mrbackup 12402 12401 0 01:30 ? 00:00:00 /bin/sh -c /home/mrbackup/backup.sh
mrbackup 12403 12402 0 01:30 ? 00:00:00 /bin/bash /home/mrbackup/backup.sh
mrbackup 12412 12403 0 01:30 ? 00:00:00 /bin/bash /home/mrbackup/backup.sh
mrbackup 12428 12412 0 01:30 ? 00:00:11 docker exec -t quassel_postgres_1 pg_dumpall -v --lock-wait-timeout=600 -c -U postgres
root 12449 11150 0 01:30 ? 00:00:00 pg_dumpall -v --lock-wait-timeout=600 -c -U postgres
root 12467 12449 0 01:30 ? 00:00:00 sh -c "/usr/local/bin/pg_dump" -v --lock-wait-timeout '600' -Fp 'user=postgres dbname=quassel'
root 12468 12467 0 01:30 ? 00:00:16 /usr/local/bin/pg_dump -v --lock-wait-timeout 600 -Fp user=postgres dbname=quassel
strace mostra que a maioria dos subprocessos do pg_dump espera por um bloqueio?
futex(0xc42054cd38, FUTEX_WAIT, 0, NULL
dois dos processos reiniciam um syscall:
restart_syscall(<... resuming interrupted futex ...>)
tentando analisar o banco de dados com esta consulta:
SELECT a.datname,
c.relname,
l.mode,
l.GRANTED,
a.wait_event_type,
a.usename,
a.query,
a.query_start,
age(now(), a.query_start) AS "age",
a.pid
FROM pg_stat_activity a
JOIN pg_locks l ON l.pid = a.pid
JOIN pg_class c ON c.oid = l.relation
WHERE
NOW() - query_start > '10 second';
ORDER BY a.query_start;
me dá o seguinte:
datname | relname | mode | granted | wait_event_type | usename | query | query_start | age | pid
---------+-----------------------------------------+-----------------+---------+-----------------+----------+--------------------------------------------------+-------------------------------+-----------------+-------
quassel | pg_attribute_relid_attnum_index | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_attribute_relid_attnam_index | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_attribute | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_class | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_init_privs_o_c_o_index | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_roles | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_init_privs | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
quassel | pg_depend_reference_index | AccessShareLock | t | | postgres | COPY public.sender (senderid, sender) TO stdout; | 2018-07-21 23:30:18.253695+00 | 07:11:41.798605 | 25095
e mais 100 linhas
EDITAR
Eu consertei meu problema inicial, mas ainda estaria interessado em saber por que o tubo quebra. Além disso, por que o processo não termina nessa situação.