Boa tarde Daniel,
O tempo para chegar um arquivo do master para a replica é de milesegundos.
O envio do archive quando gravado no pg_xlog é enviado para a replica
instantaneamente.
O arquivo gerado no pg_xlog da master é recebido na replica e visto da
seguinte forma.
12819 postgres 20 0 35,692g 3572 1928 S 2,7 0,0 65:16.78
postgres: wal receiver process streaming 8DF/7DD0000
Quanto ao tempo de atraso ele pode ser calculado da seguinte forma.
SELECT (CASE WHEN pg_last_xlog_receive_location() =
pg_last_xlog_replay_location()
THEN 0
ELSE EXTRACT (EPOCH FROM now() -
pg_last_xact_replay_timestamp())
END) AS log_delay;
Já a movimentação para o PG_XLOG é feita pelo proprio stream replication,
não havendo nenhuma configuração. O trafego destes arquivo para a replica é
feito atravez da configuração recovery.conf.
standby_mode = 'on'
primary_slot_name = 'slot'
primary_conninfo = 'host=hostname port=5433 user=replication
trigger_file = '/var/lib/pgsql/9.6/data/im_the_master
Att,
Em 30 de agosto de 2017 13:54, Daniel Luiz da Silva <daniel.si...@ipm.com.br
> escreveu:
>
> ------------------------------
> *De: *"Marcelo Kruger" <marcelo.kru...@neoway.com.br>
> *Para: *pgbr-geral@listas.postgresql.org.br
> *Enviadas: *Quarta-feira, 30 de agosto de 2017 12:09:56
> *Assunto: *[pgbr-geral] Lentidão na aplicação do Archive - Stream
> Replication
>
> Boa tarde a todos,
> Possuimos uma arquitetura na nuvem da Azure com duas maquinas de banco com
> a versão 9.6 do Postgres. Esta estrutura trabalha com uma maquina sendo o
> banco principal, e a outra sendo a replica deste banco. A replicação é de
> forma assincrona e via Stream Replication, utilizando um Slot para
> replicação.
>
> Ambas as maquinas possuem os mesmos recursos de hardware, e as mesmas
> otimizações em SO
>
>
> Disco: 17TB para database, sendo 9TB consumido. Disco é um RAID 0 de
> 17SSDs de 1TB
> 144 GB de memoria
> 20 nucleos de processamento
>
> A maquina principal tem otima performance, enviando os archives do pg_xlog
> em uma rede de banda maxima de 1,5GB/s. Identificamos que não existe
> problema e lentidão no envio e recebimento dos arquivos na replica.
> Entretando quando o postgres replicado inicia o processo de recovery destes
> archives demora um tempo muito elevado, estando em media 15 segundos para
> processar um archive. Isso esta causando uma diferença de dados entre os
> bancos muito elevada, fazendo desta forma que a replicação nunca finalize o
> processamento dos archives.
>
> Hoje temos 1,6 dias de lag entre o archive da produção, e o archive da
> replica.
>
> Gostaria de apoio para resolver este problema de lentidão no momento do
> recovery destes archives
>
> 12819 postgres 20 0 35.692g 3552 1908 S 9.3 0.0 57:05.46
> postgres: wal receiver process streaming 8D8/A623D4B8
>
>
> 40604 postgres 20 0 35.686g 3184 1500 D 4.7 0.0 76:29.52
> postgres: startup process recovering 000000010000088600000038
>
> Segue abaixo configuração do postgresql.conf da replica.
>
> listen_addresses = '*'
> port = 5433
> max_connections = 2000
> superuser_reserved_connections = 3
> shared_buffers = 35257MB
> work_mem = 18051kB
> maintenance_work_mem = 8GB
> #autovacuum_work_mem = 4GB
> max_stack_depth = 5MB
> dynamic_shared_memory_type = posix
> vacuum_cost_delay = 20
> vacuum_cost_limit = 200
> bgwriter_delay = 10ms
> bgwriter_lru_maxpages = 700
> bgwriter_lru_multiplier = 2.0
> fsync = off
> synchronous_commit = off
> full_page_writes = off
> wal_buffers = 16MB
> wal_writer_delay = 1ms
> checkpoint_timeout = 10min
> max_wal_size = 8GB
> min_wal_size = 4GB
> #checkpoint_completion_target = 0.9
> effective_cache_size = 105772MB
> default_statistics_target = 500
> log_destination = 'csvlog'
> logging_collector = off
> log_directory = 'pg_log'
> log_filename = 'postgresql-%w.log'
> log_file_mode = 0640
> log_truncate_on_rotation = on
> log_rotation_age = 1d
> log_rotation_size = 600MB
> log_min_duration_statement = 0
> log_checkpoints = on
> log_connections = off
> log_disconnections = off
> log_duration = on
> log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h'
> log_lock_waits = on
> log_timezone = 'Brazil/East'
> autovacuum = on
> log_autovacuum_min_duration = -1
> autovacuum_max_workers = 8
> autovacuum_naptime = 30s
> autovacuum_vacuum_threshold = 20
> autovacuum_analyze_threshold = 20
> autovacuum_vacuum_scale_factor = 0.2
> autovacuum_analyze_scale_factor = 0.1
> autovacuum_vacuum_cost_delay = -1
> datestyle = 'iso, mdy'
> timezone = 'Brazil/East'
> lc_messages = 'en_US.UTF-8'
> lc_monetary = 'en_US.UTF-8'
> lc_numeric = 'en_US.UTF-8'
> lc_time = 'en_US.UTF-8'
> default_text_search_config = 'pg_catalog.english'
> max_locks_per_transaction = 256
> pgpool.pg_ctl = '/usr/pgsql-9.6/bin/pg_ctl'
> huge_pages=on
> hot_standby = on
> hot_standby_feedback = off
> wal_receiver_timeout = 0
>
>
> Att,
>
> Marcelo,
>
> Acho que primeiramente teria que intender o local do problema. O arquivo
> WAL quando é replicado do servidor master para o servidor slave, demora
> quanto tempo para chegar no servidor slave? Nesse modo, nunca irá termina o
> archive, ele sempre estará aguardando o arquivo WAL, caso queira observar
> no log do postgres slave ele solta a mensagem aguardando o arquivo "XYZ",
> até receber esse arquivo. Como foi calculado esse atraso em 1.6 dias?
> Existe um outro problema que dependedo do volume de gravação que recebe o
> servidor master, caso o volume seja muito alto, ele seguirá o caminho comum
> até chegar no servidor slave, levará um tempo. O que executa no parâmetro
> archive_command ? Como funciona a movimentação da pasta pg_xlog para pasta
> archive? Como está o parâmetro max_wal_senders ?
>
> Obrigado.
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
