Différences entre les réplicas en lecture pour les moteurs de bases de données

Méthode de réplication : réplication physique.

Purge des journaux de transactions : RDS for 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éplicas accessible en écriture : un réplica Db2 est une copie physique et Db2 n’autorise pas les écritures dans un réplica. Vous pouvez promouvoir un réplica afin de le rendre accessible en écriture. Le réplica promu comporte 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 les réplicas en lecture RDS for Db2.

Réplication parallèle : les données des journaux d’archive sont toujours transmises en parallèle de la base de données principale vers tous ses réplicas en lecture.

État Veille : l’utilisation principale des réplicas de secours est la reprise après sinistre entre régions. Pour plus d'informations, consultez Utilisation de réplicas pour Amazon RDS for Db2.

Méthode de réplication : réplication logique.

Purge des journaux de transactions : RDS for MySQL et RDS for MariaDB conservent les journaux binaires qui n’ont pas été appliqués.

Réplicas accessibles en écriture : vous pouvez permettre au réplica en lecture MySQL ou MariaDB d’être accessible en écriture.

Sauvegardes : les sauvegardes automatiques et les instantanés manuels sont pris en charge sur les réplicas en lecture RDS for MySQL ou RDS for MariaDB.

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

É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 primaire ne possède aucun réplica en lecture entre régions, 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 de rétablissement archivés.

Réplicas accessibles en écriture : un réplica en lecture Oracle est une copie physique et Oracle n’autorise pas les écritures dans un réplica 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 les réplicas en lecture RDS for Oracle.

Réplication parallèle : les données des journaux de rétablissement sont toujours transmises en parallèle de la base de données principale vers tous ses réplicas en lecture.

État Monté : l’utilisation principale des réplicas montés est 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 du paramètre wal_keep_segments, qui indique le nombre de fichiers WAL (write-ahead log) à conserver pour fournir les données aux réplicas en lecture. La valeur de ce paramètre spécifie le nombre de journaux à conserver.

Réplicas accessibles en écriture : un réplica en lecture PostgreSQL est une copie physique et PostgreSQL ne permet pas de rendre accessible en écriture un réplica en lecture.

Sauvegardes : les instantanés manuels sont pris en charge pour les réplicas en lecture RDS pour PostgreSQL. Les sauvegardes automatiques pour les réplicas en lecture sont prises en charge pour RDS pour 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 pour PostgreSQL antérieures à 14.1. Pour RDS pour 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 dispose d’un processus unique de 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 fichier journal des transactions sur le réplica principal peut être tronqué une fois qu’il n’est plus nécessaire pour les réplicas 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éplicas accessibles en écriture : un réplica en lecture SQL Server est une copie physique et n’autorise pas 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éplicas en lecture RDS for SQL Server.

Réplication parallèle : les données des journaux de rétablissement sont toujours transmises en parallèle de la base de données principale vers tous ses réplicas en lecture.

État monté : non pris en charge.