Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configuration et affichage de la configuration du journal binaire

Les procédures stockées suivantes définissent et affichent les paramètres de configuration, tels que la conservation des fichiers journaux binaires.

mysql.rds_set_configuration

Spécifie le nombre d'heures pendant lequel les journaux binaires doivent être conservés ou le nombre de secondes pendant lequel retarder la réplication.

Syntaxe

CALL mysql.rds_set_configuration(name,value);

Paramètres

Notes d'utilisation

La procédure mysql.rds_set_configuration prend en charge des paramètres de configuration suivants :

Les paramètres de configuration sont stockés de manière permanente et survivent à tout redémarrage ou basculement d'une instance de base de données.

nombre d'heures de conservation du journal binaire

Le paramètre binlog retention hours est utilisé pour spécifier le nombre d'heures de rétention des fichiers journaux binaires. Amazon purge RDS normalement un journal binaire dès que possible, mais le journal binaire peut toujours être nécessaire pour la réplication avec une base de SQL données My database externe àRDS.

La valeur par défaut de binlog retention hours est NULL. Pour RDS for MySQL, NULL cela signifie que les journaux binaires ne sont pas conservés (0 heure).

Pour spécifier le nombre d'heures pendant lesquelles conserver les journaux binaires sur une instance de base de données, utilisez la procédure stockée mysql.rds_set_configuration et spécifiez une période suffisamment longue pour que la réplication se produise, comme illustré dans l'exemple suivant.

call mysql.rds_set_configuration('binlog retention hours', 24);

Pour les instances My SQL DB, la binlog retention hours valeur maximale est de 168 (7 jours).

Après avoir défini la période de rétention, surveillez l'utilisation du stockage de l'instance de base de données afin de garantir que les journaux binaires conservés n'utilisent pas un espace de stockage trop grand.

Pour les déploiements de clusters de base de données multi-AZ, vous pouvez uniquement configurer la rétention des journaux binaires à partir de l'instance de base de données du rédacteur, et le paramètre est propagé à toutes les instances de base de données du lecteur de manière asynchrone. Si les journaux binaires du cluster de base de données dépassent la moitié de l'espace de stockage local total, Amazon déplace RDS automatiquement les journaux périmés vers le EBS volume. Cependant, les journaux les plus récents restent dans le stockage local. Ils sont donc susceptibles d'être perdus en cas de panne nécessitant le remplacement d'un hôte, ou si vous augmentez ou diminuez la taille de la base de données.

retard à la source

Utilisez le paramètre source delay dans un réplica en lecture pour spécifier le nombre de secondes dont il faut retarder la réplication à partir du réplica en lecture vers son instance de base de données source. Amazon réplique RDS normalement les modifications dès que possible, mais vous souhaiterez peut-être que certains environnements retardent la réplication. Par exemple, lorsque la réplication est retardée, vous pouvez restaurer par progression un réplica en lecture retardé au moment précédant un sinistre. Si une table est supprimée par mégarde, vous pouvez utiliser la réplication retardée pour la récupérer rapidement. La valeur par défaut de target delay est 0 (ne pas retarder la réplication).

Lorsque vous utilisez ce paramètre, il s'exécute mysql.rds_set_source_delay et applique la valeur d'entrée CHANGE primaire TO MASTER _ DELAY =. En cas de succès, la procédure enregistre le paramètre source delay dans la table mysql.rds_configuration.

Pour spécifier le nombre de secondes pendant lequel Amazon doit RDS retarder la réplication vers une instance de base de données source, utilisez la procédure mysql.rds_set_configuration stockée et spécifiez le nombre de secondes pendant lesquelles Amazon retarde la réplication. Dans l'exemple suivant, la réplication est retardée d'au moins une heure (3 600 secondes).

call mysql.rds_set_configuration('source delay', 3600);

La procédure exécute ensuite mysql.rds_set_source_delay(3600).

La limite du paramètre source delay est une journée (soit 86 400 secondes).

target delay

Utilisez le target delay paramètre pour spécifier le nombre de secondes nécessaires pour retarder la réplication entre une instance de base de données et toute future réplique de RDS lecture gérée créée à partir de cette instance. Ce paramètre est ignoré pour les répliques de lecture non RDS gérées. Amazon réplique RDS normalement les modifications dès que possible, mais vous souhaiterez peut-être que certains environnements retardent la réplication. Par exemple, lorsque la réplication est retardée, vous pouvez restaurer par progression un réplica en lecture retardé au moment précédant un sinistre. Si une table est supprimée par mégarde, vous pouvez utiliser la réplication retardée pour la récupérer rapidement. La valeur par défaut de target delay est 0 (ne pas retarder la réplication).

Pour la reprise après sinistre, vous pouvez utiliser ce paramètre de configuration avec la procédure stockée ou . Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure mysql.rds_set_configuration avec ce paramètre défini. Une fois que la procédure mysql.rds_start_replication_until ou mysql.rds_start_replication_until_gtid a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu'il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans Promotion d'un réplica en lecture en instance de bases de données autonome.

Pour utiliser mysql.rds_rds_start_replication_until_gtid cette procédure, la réplication GTID basée doit être activée. Pour ignorer une GTID transaction spécifique connue pour provoquer un sinistre, vous pouvez utiliser la procédure stockée. Pour plus d'informations sur l'utilisation de la réplication GTID basée, consultezUtilisation de GTID la réplication basée.

Pour spécifier le nombre de secondes pendant lequel Amazon doit RDS retarder la réplication vers une réplique en lecture, utilisez la procédure mysql.rds_set_configuration stockée et spécifiez le nombre de secondes pendant lequel Amazon retarde la réplication. L'exemple suivant spécifie que la réplication est retardée d'au moins une heure (3 600 secondes).

call mysql.rds_set_configuration('target delay', 3600);

La limite du paramètre target delay est une journée (soit 86 400 secondes).

mysql.rds_show_configuration

Nombre d'heures pendant lequel les journaux binaires sont conservés.

Syntaxe

CALL mysql.rds_show_configuration;

Notes d'utilisation

Pour vérifier le nombre d'heures pendant lesquelles Amazon RDS conserve les journaux binaires, utilisez la procédure mysql.rds_show_configuration stockée.

Exemples

L'exemple suivant affiche la période de rétention :

call mysql.rds_show_configuration;
                name                         value     description
                binlog retention hours       24        binlog retention hours specifies the duration in hours before binary logs are automatically deleted.