Différences entre les répliques de lecture pour les moteurs de base de données

Méthode de réplication — Réplication physique.

Purge des journaux de transactions — RDS pour DB2 purge les journaux de l'instance de base de données principale lorsque les conditions suivantes sont remplies :

Cela s'applique à la fois aux mêmes Région AWS instances de base de données et aux instances de base de données interrégionales. Pour plus d'informations sur la définition des heures de conservation des journaux d'archivage, veuillez consulter rdsadmin.set_archive_log_retention.

Répliques inscriptibles — Une réplique Db2 est une copie physique, et Db2 n'autorise pas les écritures dans une réplique. Vous pouvez promouvoir la réplique pour la rendre inscriptible. La réplique promue contient les données répliquées au moment où la demande de promotion a été faite.

Sauvegardes — Les sauvegardes automatiques et les instantanés manuels sont pris en charge sur RDS pour les répliques DB2.

Réplication parallèle : les données du journal d'archivage sont toujours transmises en parallèle de la base de données principale à toutes ses répliques.

État de veille : les répliques de secours sont principalement utilisées pour la reprise après sinistre entre régions. Pour plus d'informations, consultez Utilisation de répliques pour Amazon RDS pour DB2.

Méthode de réplication — Réplication logique.

Purge des journaux de transactions — RDS pour MariaDB et RDS pour MySQL conservent tous les journaux binaires qui n'ont pas été appliqués.

Répliques inscriptibles — Vous pouvez activer la réplique en lecture MariaDB ou MySQL pour qu'elle soit accessible en écriture.

Sauvegardes — Les sauvegardes automatiques et les instantanés manuels sont pris en charge sur les répliques de lecture RDS pour MariaDB ou RDS pour MySQL.

Réplication parallèle — Toutes les versions de MariaDB et MySQL prises en charge autorisent les threads de réplication parallèles.

État monté : non pris en charge.

Méthode de réplication — Réplication physique.

Purge des journaux de transactions : si une instance de base de données principale ne possède pas de répliques de lecture interrégionales, Amazon RDS for Oracle conserve un minimum de deux heures de journaux de transactions sur l'instance de base de données source. Les journaux sont purgés de l'instance de base de données source au bout de deux heures ou une fois que le paramètre d'heures de conservation du journal d'archive est passé, le plus long des deux. Les journaux sont purgés du réplica en lecture une fois que le paramètre d'heures de conservation du journal d'archive est passé, uniquement s'ils ont été appliqués correctement à la base de données.

Dans certains cas, une instance de base de données principale peut avoir un ou plusieurs réplicas en lecture entre régions. Dans ce cas, Amazon RDS for Oracle conserve les journaux de transaction sur l'instance de base de données source jusqu'à ce qu'ils aient été transmis et appliqués à tous les réplicas en lecture entre régions.

Pour plus d'informations sur la définition des heures de conservation des journaux d'archivage, veuillez consulter Conservation des journaux redo archivés.

Répliques inscriptibles : une réplique en lecture Oracle est une copie physique, et Oracle n'autorise pas les écritures dans une réplique en lecture. Vous pouvez promouvoir un réplica en lecture afin de le rendre inscriptible. Le réplica en lecture promu a les données répliquées jusqu'au moment où la demande a été faite pour le promouvoir.

Sauvegardes : les sauvegardes automatiques et les instantanés manuels sont pris en charge sur RDS pour les répliques de lecture Oracle.

Réplication parallèle — Les données du Redo Log sont toujours transmises en parallèle de la base de données principale à toutes ses répliques en lecture.

État monté : les répliques montées sont principalement utilisées pour la reprise après sinistre entre régions. Une licence Active Data Guard n'est pas requise pour les réplicas montés. Pour de plus amples informations, veuillez consulter Utilisation de réplicas en lecture pour Amazon RDS for Oracle.

Méthode de réplication — Réplication physique.

Purge des journaux de transactions : PostgreSQL dispose d'un wal_keep_segments paramètre qui détermine le nombre de fichiers journaux d'écriture anticipée (WAL) à conserver pour fournir des données aux répliques en lecture. La valeur de ce paramètre spécifie le nombre de journaux à conserver.

Répliques inscriptibles : une réplique en lecture de PostgreSQL est une copie physique, et PostgreSQL ne permet pas de rendre une réplique en lecture accessible en écriture.

Sauvegardes : les instantanés manuels sont pris en charge pour les répliques de lecture RDS pour PostgreSQL. Les sauvegardes automatiques pour les réplicas en lecture sont prises en charge pour RDS for PostgreSQL 14.1 et versions ultérieures uniquement. Vous ne pouvez pas activer les sauvegardes automatiques pour les réplicas en lecture PostgreSQL pour les versions de RDS for PostgreSQL antérieures à 14.1. Pour RDS for PostgreSQL 13 et versions antérieures, créez un instantané à partir d'un réplica en lecture si vous souhaitez en obtenir une sauvegarde.

Réplication parallèle : PostgreSQL utilise un seul processus pour gérer la réplication.

État monté : non pris en charge.

Méthode de réplication — Réplication physique.

Purge des journaux de transactions — Le fichier journal virtuel (VLF) du journal des transactions du réplica principal peut être tronqué une fois qu'il n'est plus nécessaire pour les répliques secondaires.

Le VLF ne peut être marqué comme inactif que lorsque les enregistrements de journaux ont été sécurisés dans les réplicas. Quelle que soit la rapidité avec laquelle les sous-systèmes de disque se trouvent dans la réplique principale, le journal des transactions le conservera VLFs jusqu'à ce que la réplique la plus lente l'ait durcie.

Répliques inscriptibles : une réplique en lecture de SQL Server est une copie physique et n'autorise pas non plus les écritures. Vous pouvez promouvoir un réplica en lecture afin de le rendre inscriptible. Le réplica en lecture promu a les données répliquées jusqu'au moment où la demande a été faite pour le promouvoir.

Sauvegardes : les sauvegardes automatiques et les instantanés manuels ne sont pas pris en charge sur les répliques en lecture de RDS pour SQL Server.

Réplication parallèle — Les données du Redo Log sont toujours transmises en parallèle de la base de données principale à toutes ses répliques en lecture.

État monté : non pris en charge.