Diferenças entre réplicas de leitura para mecanismos de banco de dados

Método de replicação – replicação física.

Expurgação de logs de transações – o RDS para Db2 expurgará os logs da instância de banco de dados primária quando as seguintes condições forem atendidas:

Isso se aplica tanto às instâncias de banco de dados da Região da AWS quanto às instâncias de banco de dados entre regiões. Para obter informações sobre como definir horas de retenção de log de arquivamento, consulte rdsadmin.set_archive_log_retention.

Réplicas graváveis – uma réplica do Db2 é uma cópia física e o Db2 não permite gravações em uma réplica. É possível promover a réplica para torná-la gravável. A réplica promovida terá os dados replicados para o ponto quando a solicitação foi feita para promovê-la.

Backups – backups automáticos e snapshots manuais são compatíveis com réplicas do RDS para Db2.

Replicação paralela – os dados de log de arquivamento são sempre transmitidos em paralelo do banco de dados primário para todas as réplicas.

Estado de espera – o principal uso para réplicas de espera é a recuperação de desastres entre regiões. Para mais informações, consulte Trabalhar com réplicas para o Amazon RDS para Db2.

Método de replicação – replicação lógica.

Limpeza dos logs de transação – o RDS para MariaDB e o RDS para MySQL mantêm todos os logs binários que não foram aplicados.

Réplicas graváveis – é possível permitir que uma réplica de leitura do MariaDB ou do MySQL seja gravável.

Backups – backups automáticos e snapshots manuais são compatíveis com réplicas de leitura do RDS para MariaDB ou do RDS para MySQL.

Replicação paralela – todas as versões do MariaDB e do MySQL permitem threads de replicação paralelos.

Estado montado – não suportado.

Método de replicação – replicação física.

Limpeza dos logs de transação – se uma instância de banco de dados primária não tiver réplicas de leitura entre regiões, o Amazon RDS para Oracle manterá um mínimo de duas horas de logs de transação na instância de banco de dados de origem. Os logs serão limpos da instância de banco de dados de origem após duas horas ou após o tempo definido na configuração de horas de retenção do log de arquivamento, o que for maior. Os logs serão removidos da réplica de leitura após o tempo definido pela configurações horas de retenção do log de arquivamento somente se eles tiverem sido aplicados com êxito ao banco de dados.

Em alguns casos, uma instância de banco de dados primária pode ter uma ou mais réplicas de leitura entre regiões. Nesse caso, o Amazon RDS for Oracle mantém os logs de transações na instância do banco de dados de origem até que eles tenham sido transmitidos e aplicados a todas as réplicas de leitura entre regiões.

Para obter informações sobre como definir horas de retenção de log de arquivamento, consulte Retenção de logs redo arquivados.

Réplicas graváveis – uma réplica de leitura do Oracle é uma cópia física, e o Oracle não permite gravações em uma réplica de leitura. É possível promover a réplica de leitura para torná-la gravável. A réplica de leitura promovida terá os dados replicados para o ponto quando a solicitação foi feita para promovê-la.

Backups – backups automáticos e snapshots manuais são compatíveis com réplicas de leitura do RDS para Oracle.

Replicação paralela – os dados de log redo são sempre transmitidos em paralelo do banco de dados primário para todas as réplicas de leitura.

Estado montado – o principal uso para réplicas montadas é a recuperação de desastres entre regiões. Uma licença do Active Data Guard não é necessária para réplicas montadas. Para obter mais informações, consulte Trabalhar com réplicas de leitura do Amazon RDS para Oracle.

Método de replicação – replicação física.

Limpeza dos logs de transação – o PostgreSQL tem o parâmetro wal_keep_segments, que determina quantos arquivos de log prévio de gravação (WAL) são mantidos para fornecer dados às réplicas de leitura. O valor de parâmetro especifica o número de logs a serem mantidos.

Réplicas graváveis – uma réplica de leitura do PostgreSQL é uma cópia física e o PostgreSQL não permite que uma réplica de leitura torne-se gravável.

Backups – snapshots manuais são compatíveis com réplicas de leitura do RDS for PostgreSQL. Os backups automatizados de réplicas de leitura são compatíveis apenas com o RDS para PostgreSQL 14.1 e versões superiores. Não é possível ativar backups automatizados de réplicas de leitura do PostgreSQL de versões do RDS para PostgreSQL anteriores à 14.1. Para o RDS para PostgreSQL 13 e versões anteriores, crie um instantâneo de uma réplica de leitura para criar um backup dele.

Réplica paralela – o PostgreSQL tem um processo único que gerencia a replicação.

Estado montado – não suportado.

Método de replicação – replicação física.

Limpeza dos logs de transação – o arquivo de log virtual (VLF) do arquivo de log de transação na réplica primária poderá ficar truncado depois que ele não for mais necessário para as réplicas secundárias.

O VLF só poderá ser marcado como inativo quando os registros de log tiverem sido reforçados nas réplicas. Independentemente da rapidez com que os subsistemas de disco estejam na réplica primária, o log de transações manterá os VLFs até que a réplica mais lenta o tenha reforçado.

Réplicas graváveis – uma réplica de leitura do SQL Server é uma cópia física e também não permite gravações. É possível promover a réplica de leitura para torná-la gravável. A réplica de leitura promovida terá os dados replicados até o ponto quando a solicitação foi feita para promovê-la.

Backups – backups automáticos e snapshots manuais não são compatíveis com réplicas de leitura do RDS para SQL Server.

Replicação paralela – os dados de log redo são sempre transmitidos em paralelo do banco de dados primário para todas as réplicas de leitura.

Estado montado – não suportado.