# Visão geral da replicação lógica do PostgreSQL com o Aurora Ao usar o recurso de replicação lógica do PostgreSQL com seu cluster de banco de dados do Aurora PostgreSQL, você pode replicar e sincronizar tabelas individuais em vez de toda a instância do banco de dados. A replicação lógica usa um modelo de publicação e de assinatura para replicar as alterações de uma fonte para um ou mais destinatários. Ela funciona usando registros de alterações do log de gravação antecipada (WAL) do PostgreSQL. A fonte, ou o *editor*, envia os dados WAL das tabelas especificadas a um ou mais destinatários (*assinante*), replicando, dessa forma, as alterações e mantendo a tabela do assinante sincronizada com a tabela do editor. O conjunto de alterações do editor é identificado por meio de uma *publicação*. Os assinantes recebem as alterações criando uma *assinatura* que define a conexão com o banco de dados do editor e suas publicações. Um *slot de replicação* é o mecanismo utilizado nesse esquema para monitorar o andamento de uma assinatura. Para clusters de banco de dados do Aurora PostgreSQL, os registros WAL são salvos no armazenamento do Aurora. O cluster de banco de dados do Aurora PostgreSQL que atua como editor em um cenário de replicação lógica lê os dados WAL do armazenamento do Aurora, os decodifica e os envia ao assinante para que as alterações possam ser aplicadas à tabela nessa instância. O editor usa um *decodificador lógico* para decodificar os dados a serem utilizados pelos assinantes. Por padrão, os clusters de banco de dados do Aurora PostgreSQL usam o plug-in `pgoutput` nativo do PostgreSQL ao enviar dados. Outros decodificadores lógicos estão disponíveis. Por exemplo, o Aurora PostgreSQL também é compatível com o plug-in `[wal2json](https://github.com/eulerto/wal2json)` que converte dados WAL em JSON. A partir das versões 14.5, 13.8, 12.12 e 11.17 do Aurora PostgreSQL, o Aurora PostgreSQL incrementa o processo de replicação lógica do PostgreSQL com um *cache de gravação* para melhorar a performance. Os logs de transações do WAL são armazenados em cache localmente, em um buffer, para reduzir a quantidade de E/S do disco, ou seja, a leitura do armazenamento do Aurora durante a decodificação lógica. O cache de gravação é usado por padrão sempre que você usa a replicação lógica para o cluster de banco de dados do Aurora PostgreSQL. O Aurora fornece várias funções que você pode usar para gerenciar o cache. Para obter mais informações, consulte [Monitorar o cache de gravação simultânea de replicação lógica do Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache). A replicação lógica é compatível com todas as versões do Aurora PostgreSQL atualmente disponíveis. Para obter informações, [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) (Atualizações do Amazon Aurora PostgreSQL) nas *Release Notes for Aurora PostgreSQL* (Notas de versão do Aurora PostgreSQL). A replicação lógica é compatível com o Babelfish para Aurora PostgreSQL a partir das seguintes versões: + 15.7 e versões posteriores + 16.3 e versões posteriores **nota** Além do recurso nativo de replicação lógica do PostgreSQL introduzido no PostgreSQL 10, o Aurora PostgreSQL também é compatível com a extensão `pglogical`. Para obter mais informações, consulte [Usar pglogical para sincronizar dados entre instâncias](Appendix.PostgreSQL.CommonDBATasks.pglogical.md). Para obter informações detalhadas sobre a replicação lógica do PostgreSQL, consulte [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) (Replicação lógica) e [Logical decoding concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) (Conceitos da decodificação lógica) na documentação do PostgreSQL. **nota** O PostgreSQL 16 adicionou suporte para decodificação lógica por meio de réplicas de leitura. Esse recurso não é aceito no Aurora PostgreSQL.