PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Configurando o PostgreSQL para continuidade de negócios

Continuidade de negócios para bancos de dados


A continuidade de negócios para bancos de dados significa que os bancos de dados devem estar continuamente operacionais mesmo durante os desastres. É imperativo garantir que os bancos de dados de produção estejam disponíveis para os aplicativos o tempo todo, mesmo durante os desastres, caso contrário, pode acabar sendo um negócio caro. DBAs, Arquitetos precisariam garantir que os ambientes de banco de dados possam suportar desastres e sejam compatíveis com SLA de recuperação de desastres. Para garantir que desastres não afetem a disponibilidade do banco de dados, os bancos de dados devem ser configurados para continuidade de negócios.

A configuração de bancos de dados para continuidade de negócios envolve muita arquitetura, planejamento, design e teste. Muitos fatores, como data centers e seus territórios geográficos, incluindo design de infraestrutura, são levados em consideração quando se trata de projetar e implementar uma estratégia eficaz de recuperação de desastres para bancos de dados. Isso explica o fato de que “Continuidade dos negócios =Evitar interrupções durante desastres ”.

Para garantir que os bancos de dados de produção sobrevivam a um desastre, um site de recuperação de desastres (DR) deve ser configurado. Os sites de produção e DR devem fazer parte de dois Data Centers geograficamente distantes. Isso significa que um banco de dados em espera deve ser configurado no site de DR para cada banco de dados de produção para que as alterações de dados que ocorrem no banco de dados de produção sejam imediatamente sincronizadas com o banco de dados em espera por meio de logs de transação. Isso pode ser alcançado pelo recurso “Streaming Replication” no PostgreSQL.

O que precisa acontecer se um desastre atingir o banco de dados de produção (ou primário)?


Quando o banco de dados de produção (primário) trava ou não responde, o banco de dados em espera deve ser promovido para primário e os aplicativos devem ser apontados para o banco de dados em espera recém-promovido (novo primário) e tudo isso deve acontecer automaticamente dentro do SLA de interrupção designado. Este processo é denominado como failover.

Configurando o PostgreSQL para alta disponibilidade


Como dito acima, para garantir que o PostgreSQL seja compatível com recuperação de desastres, ele deve primeiro ser configurado com Streaming Replication (master + standby database) e com recursos automáticos de promoção/failover em standby. Vejamos como configurar a replicação de streaming primeiro e depois o processo de “failover”.

Configurando o banco de dados em espera (replicação de streaming)


A replicação de streaming é o recurso interno do PostgreSQL que garante que os dados sejam replicados do banco de dados Primário para o Standby por meio de registros WAL e suporta métodos de replicação assíncrona e síncrona. Essa forma de replicação é bastante confiável e adequada para ambientes que exigem replicação em tempo real e de alto desempenho.

Configurar o modo de espera de streaming é bastante simples. A primeira etapa é garantir que as configurações do banco de dados primário sejam as seguintes:

Configurações obrigatórias do banco de dados primário


Certifique-se de que os parâmetros a seguir estejam configurados em postgresql.conf no banco de dados primário. Fazer as alterações a seguir exigiria uma reinicialização do banco de dados. 
wal_level=logical

O parâmetro wal_level garante que as informações necessárias para a replicação sejam gravadas nos arquivos WAL. 
max_wal_senders=1 (or any number more than 0)

Os registros WAL são enviados pelo processo wal sender do banco de dados primário para o banco de dados de reserva. Portanto, o parâmetro acima deve ser configurado para no mínimo 1. Mais de um valor de 1 é necessário quando vários remetentes wal são necessários.

Ativar arquivamento WAL


Não há dependência rígida do WAL Archiving para replicação de streaming. No entanto, é altamente recomendável configurar o WAL Archiving porque, se o standby ficar para trás e se os arquivos WAL necessários forem removidos do diretório pg_xlog (ou pg_wal), os arquivos Archive serão necessários para obter o standby em sincronia com o diretório primário. caso contrário, o modo de espera deve ser reconstruído do zero. 
archive_mode=on
archive_command=<archive location>

O banco de dados primário deve ser configurado para aceitar conexões do modo de espera.

A configuração abaixo deve estar lá em pg_hba.conf 
host    replication     postgres        <standby-database-host-ip>/32            trust

Agora, faça um backup do banco de dados primário e restaure o mesmo no site de DR. Uma vez feita a restauração, construa o arquivo recovery.conf no diretório de dados com o conteúdo abaixo:
standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’

Agora, inicie o banco de dados em espera. A replicação de streaming deve estar habilitada. A mensagem abaixo no arquivo de log postgresql do banco de dados standby confirma que a replicação de streaming está funcionando com sucesso:
2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG:  started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG:  redo starts at 127/CD380170

Isso conclui que uma replicação de streaming totalmente funcional está em vigor. Próxima etapa para instalar/configurar o repmgr. Antes disso, vamos entender o processo de failover.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper

O que é Failover?


O failover ocorre quando o banco de dados primário fica completamente indisponível devido a um desastre. Durante o processo de failover, o banco de dados Standby será promovido para se tornar um novo banco de dados primário para que os aplicativos possam continuar as operações de negócios.

Failover automático


Todo o processo de failover precisa acontecer automaticamente para garantir a continuidade efetiva dos negócios e isso só pode ser alcançado por algumas ferramentas de middleware. A ideia toda é evitar uma intervenção manual de DBAs, Desenvolvedores.

Uma dessas ferramentas que ajuda a realizar o failover automático é o “repmgr”.

Vamos dar uma olhada no repmgr e suas capacidades.

Repmgr


Repmgr é uma ferramenta de código aberto desenvolvida pelo 2º Quadrante. Essa ferramenta ajuda a executar várias atividades administrativas de banco de dados, como criar e monitorar a replicação do PostgreSQL, incluindo a realização de atividades de failover automatizadas em caso de desastre e também ajuda a realizar operações de alternância.

Repmgr é uma ferramenta fácil de instalar e as configurações também não são complexas. Vamos dar uma olhada na instalação primeiro:

Instalando o repmgr


Baixe a ferramenta aqui.

Descompacte o tarball e execute a instalação conforme mostrado abaixo:

Instalei o repmgr-4.2.0 em um host CentOS 7 e instalei o repmgr no PostgreSQL-11.1. Antes da instalação, certifique-se de que o diretório bin do PostgreSQL faça parte do $PATH e o diretório lib do PostgreSQL faça parte do $LD_LIBRARY_PATH. Para entender que o repmgr está instalado no PostgreSQL-11.1, estou exibindo a saída “make install” abaixo:
[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755  repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql  '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'

Configurando repmgr para failover automático


Antes de configurar o “repmgr”, os bancos de dados devem ser configurados com a replicação de streaming que vimos anteriormente. Para começar, ambos os bancos de dados (primário e standby) devem ser configurados com o seguinte parâmetro em postgresql.conf:
Primary

[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Standby

[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

O parâmetro acima é para habilitar o daemon “repmgrd” que, continuamente, é executado em segundo plano e monitora a replicação de streaming. Sem este parâmetro, não é possível realizar o failover automático. Alterar este parâmetro exigiria uma reinicialização do banco de dados.
Em seguida, construa o arquivo de configuração repmgr (digamos com o nome repmgr.conf) para ambos os bancos de dados. O banco de dados primário deve ter um arquivo de configuração com o seguinte conteúdo:
node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

Coloque o arquivo no diretório de dados, neste caso, é “/data/pgdata11”.

O arquivo de configuração do banco de dados em espera deve ter o seguinte conteúdo:
node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'

failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'

monitoring_history=yes
monitor_interval_secs=5

log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG

promote_check_timeout=5
promote_check_interval=1

master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10

Ambos os bancos de dados devem ser registrados com repmgr.
Registrar banco de dados primário 
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered

Registrar banco de dados em espera 
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registered

Execute o comando abaixo para garantir que o log do repmgr esteja funcionando. 
[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"

Se você puder observar, configurei log_level para DEBUG para gerar log detalhado no arquivo repmgr.conf do standby. Verifique os logs quanto ao status da replicação.
Verifique se a replicação está funcionando conforme o esperado usando repmgr:
[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2

A mensagem acima confirma que a replicação está funcionando bem.

Agora, se eu desligar o banco de dados primário, o daemon repmgrd deve detectar a falha do banco de dados primário e deve promover o banco de dados em espera. Vamos ver se isso acontece -O banco de dados primário está parado:
[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

O banco de dados em espera deve ser promovido automaticamente. Os logs do repmgr mostrariam o mesmo:
fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name     FROM repmgr.nodes n    WHERE n.upstream_node_id = 1      AND n.node_id != 2      AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
  "repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl  -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary

O acima significa precisamente que o repmgr não conseguiu se conectar ao banco de dados primário e, após 5 tentativas malsucedidas, o standby é promovido para o novo banco de dados primário. Abaixo está o que mostra os logs do banco de dados em espera promovido (novo primário):

2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "xxx.xxx.xx.xx" and accepting
                TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG:  received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG:  redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG:  last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG:  selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG:  archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG:  checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG:  database system is ready to accept connections

Mencionei apenas os parâmetros importantes no arquivo de configuração repmgr. Existem muitos outros parâmetros que podem ser modificados para atender a vários requisitos. Os outros parâmetros importantes são os parâmetros replication_lag_*, conforme mostrado abaixo:
#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgr verificaria os limites dos parâmetros acima antes de promover o modo de espera. Se o atraso de replicação for crítico, a promoção não será realizada. O que é muito bom porque se o standby for promovido quando houver um atraso, isso resultaria em perda de dados.

Os aplicativos devem garantir que eles se reconectam ao modo de espera recém-promovido com êxito dentro do prazo esperado. Os balanceadores de carga teriam a capacidade de desviar as conexões do aplicativo quando o banco de dados primário deixar de responder. A outra alternativa seria usar ferramentas de middleware como o PgPool-II para garantir que todas as conexões sejam desviadas com sucesso.

Para garantir que a arquitetura de alta disponibilidade bem-sucedida seja implantada na produção, testes completos de ponta a ponta de todo o processo devem ser executados. Na minha experiência, costumamos chamar este exercício de DR DRILL. Ou seja, a cada 6 meses ou mais, uma operação de alternância seria executada para garantir que o modo de espera seja promovido com êxito e que as conexões do aplicativo estejam se reconectando ao modo de espera promovido com êxito. O primário existente se tornará um novo standby. Depois que a operação de alternância for bem-sucedida, as métricas serão removidas para verificar se os SLAs foram atendidos.

O que é a alternância?


Conforme explicado acima, o Switchover é uma atividade planejada em que as funções do banco de dados Primário e Standby são alternadas. Ou seja, Standby se tornará primário e primário se tornará standby. Usando repmgr, isso pode ser alcançado. Abaixo está o que o repmgr faz quando o comando de alternância é emitido. 
$ repmgr -f /etc/repmgr.conf standby switchover
    NOTICE: executing switchover on node "node2" (ID: 2)
    INFO: searching for primary node
    INFO: checking if node 1 is primary
    INFO: current primary node is 1
    INFO: SSH connection to host "node1" succeeded
    INFO: archive mode is "off"
    INFO: replication lag on this standby is 0 seconds
    NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
    NOTICE: stopping current primary node "node1" (ID: 1)
    NOTICE: issuing CHECKPOINT
    DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
    INFO: checking primary status; 1 of 6 attempts
    NOTICE: current primary has been cleanly shut down at location 0/0501460
    NOTICE: promoting standby to primary
    DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
    server promoting
    NOTICE: STANDBY PROMOTE successful
    DETAIL: server "node2" (ID: 2) was successfully promoted to primary
    INFO: setting node 1's primary to node 2
    NOTICE: starting server using  "pg_ctl -D '/data/pgdata11' restart"
    NOTICE: NODE REJOIN successful
    DETAIL: node 1 is now attached to node 2
    NOTICE: switchover was successful
    DETAIL: node "node2" is now primary
    NOTICE: STANDBY SWITCHOVER is complete

O que mais o repmgr pode fazer?

  • Repmgr pode ajudar a construir os bancos de dados standby do zero
  • Vários bancos de dados em espera podem ser criados com um mestre em execução
  • Os standbys em cascata podem ser construídos, o que considero mais benéfico do que configurar vários standbys para um banco de dados mestre

E se o primário e o de espera desaparecerem?


Bem, esta é uma situação em que as empresas pensam em ter várias instâncias de espera. Se todos eles desaparecerem, a única saída é restaurar o banco de dados dos backups. Esta é a razão pela qual uma boa estratégia de backup é imperativa. Os backups devem ser restaurados por teste, validados regularmente para garantir que os backups sejam confiáveis. O design da infraestrutura para backups deve ser tal que a restauração e a recuperação dos backups não demorem muito. O processo de restauração e recuperação dos backups deve ser concluído dentro do SLA designado. Os SLAs para backups são projetados em termos de RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação). Ou seja, RTO:o tempo necessário para restaurar e recuperar o backup deve estar dentro do SLA e do RPO:até que ponto a recuperação foi feita deve ser aceitável, em outros termos, é tolerância à perda de dados e geralmente as empresas dizem 0 perda de dados tolerância.

Conclusão

  • A continuidade dos negócios para PostgreSQL é um requisito importante para ambientes de banco de dados de missão crítica. Conseguir isso envolve muito planejamento e custos.
  • Recursos e infraestrutura devem ser utilizados de forma otimizada para garantir que uma estratégia eficiente de recuperação de desastres esteja em vigor.
  • Pode haver desafios da perspectiva de custos que precisam ser atendidos
  • Se o orçamento permitir, verifique se há vários sites de DR para failover
  • Caso os backups precisem ser restaurados, verifique se uma boa estratégia de backup está em vigor.