Nesta solução temos um PostgreSQL Master, o qual pode receber gravações e leituras, um PostgreSQL Slave conectado ao Master via Streaming Replication, o qual somente pode receber leituras. Abaixo deste slave, temos a replicação em cascata para outros slaves, que também podem ser utilizados para leitura.
O backup nesta arquitetura está sendo realizado a partir de uma das réplicas para não representar nenhum tipo impacto nesta solução. Mesmo utilizando os recursos nativos do PostgreSQL para backup PITR, neste cenário estamos utilizando a ferramenta Barman para facilitar a gerência do backup, com eles podemos comandar de maneira simples novos backups base, comandar restauração local ou remota, consultar estado de backups bem como definir políticas de retenção. Outro benefício de utilizar o Barman é redução de uso espaço em disco para o backup pois ele tem mecanismo para compactação dos WAL files e a de duplicação dos arquivos dos backups base através de recurso de backup incremental. Essa arquitetura ainda prevê o uso do Pgpool-II, cujo papel é realizar o direcionamento de querys de escrita para o servidor master e o balanceamento das consultas de leitura entre os servidores slaves. Para a aplicação todo esse mecanismo é transparente, ela se conecta ao Pgpool-II da mesma maneira que trata uma conexão direta ao banco. Para evitar que o Pgpool-II se torne um SPOF (Single Point Of Failure), ele mesmo já prove o recurso de alta disponibilidade através de IP flutuante.
