Em 23 de março de 2017 17:57, Luiz Carlos L. Nogueira Jr. < [email protected]> escreveu:
> > Quando acabou o load, fiz um pg_ctl restart e depois de algum tempo notei > que o WAL SENDER parou pro slave "lento" e só voltou depois que todos os > XLOg foram aplicado no servidor lento. > > Eu não entendi o que quis dizer aqui. "restart" em qual servidor? O que quis dizer com o resto da frase? Você fez um strace no processo do wal sender para entender porque ele estava "parado"? > Quando o WAL SENDER manda os WALS pros slaves? > Assim que ele estiver disponível no WAL (se synchronous_commit for 'on' será imediatamente após o COMMIT). > Como saber se o WAL SENDER mandou todos os WALS para todos os slaves? > Visão pg_stat_replication fornece as posições do WAL para as várias fases (sent, write, flush e replay). Que fique claro, ao usar streaming, ele não envia arquivos, ele lê os arquivos do WAL e vai enviando blocos de dados de tamanho variável (de até 128 kB, por padrão). No exemplo abaixo é utilizado a função pg_xlog_location_diff para calcular o atraso de aplicação do WAL no slave (o mesmo pode ser feito para write e flush). Se você notar o WAL já foi escrito no slave (sent_location = flush_location), porém, ainda não está disponível porque ainda não foi aplicado (replay). postgres=# select *, pg_size_pretty(pg_xlog_location_diff(sent_location, replay_location)) as lag_replay from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 10244 usesysid | 16402 usename | repl application_name | walreceiver client_addr | 10.10.5.7 client_hostname | client_port | 43689 backend_start | 2017-02-23 17:14:00.811239-03 state | streaming sent_location | 818/13186C0 write_location | 818/13186C0 flush_location | 818/13186C0 replay_location | 817/AEC87388 sync_priority | 0 sync_state | async lag_replay | 1319 MB -[ RECORD 2 ]----+------------------------------ pid | 57128 usesysid | 16402 usename | repl application_name | walreceiver client_addr | 10.10.5.8 client_hostname | client_port | 51454 backend_start | 2017-03-07 19:06:12.168277-03 state | streaming sent_location | 818/13186C0 write_location | 818/13186C0 flush_location | 818/13186C0 replay_location | 817/D1244FB0 sync_priority | 0 sync_state | async lag_replay | 769 MB -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento <http://www.timbira.com.br>
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
