Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Festlegen und Anzeigen der Konfiguration des Binärprotokolls Die folgenden gespeicherten Prozeduren legen Konfigurationsparameter fest und zeigen sie an, z. B. für die Aufbewahrung binärer Protokolldateien. **Topics** + [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration) + [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Gibt die Anzahl an Stunden an, für die die Binärprotokolle aufbewahrt werden sollen, oder die Anzahl Sekunden, um die die Replikation verzögert werden soll. ### Syntax ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parameters *name* Der Name des festzulegenden Konfigurationsparameters *value* Der Wert des Konfigurationsparameters ### Nutzungshinweise Die Prozedur `mysql.rds_set_configuration` unterstützt die folgenden Konfigurationsparameter: + [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) + [Quellenverzögerung](#mysql_rds_set_configuration-usage-notes.source-delay) + [target delay](#mysql_rds_set_configuration-usage-notes.target-delay) Die Konfigurationsparameter werden dauerhaft gespeichert und überstehen jeden Neustart oder Failover der DB-Instance. #### binlog retention hours Der Parameter `binlog retention hours` wird verwendet, um die Anzahl der Stunden anzugeben, die Binärprotokolldateien aufbewahrt werden sollen. In der Regel werden binäre Protokolldateien von Amazon RDS so schnell wie möglich bereinigt. Eine binäre Protokolldatei ist möglicherweise für die Replikation mit einer außerhalb von RDS ausgeführten MySQL-Datenbank erforderlich. Der Standardwert von `binlog retention hours` ist `NULL`. Für RDS für MySQL bedeutet `NULL`, dass binäre Protokolle nicht aufbewahrt werden (0 Stunden). Um die Anzahl der Stunden zu bestimmen, für die Binärprotokolle auf einer/einem DB-Instance aufbewahrt werden sollen, verwenden Sie die gespeicherte Prozedur `mysql.rds_set_configuration` und geben Sie, wie in dem folgenden Beispiel gezeigt, einen ausreichend großen Zeitraum für die gewünschte Replikation an. `call mysql.rds_set_configuration('binlog retention hours', 24);` **Anmerkung** Sie können den Wert `0` nicht für `binlog retention hours` verwenden. Für MySQL-DB-Instances beträgt der maximal zulässige Wert für `binlog retention hours` 168 (entspricht 7 Tagen). Nachdem Sie den Aufbewahrungszeitraum festgelegt haben, überwachen Sie die Speichernutzung für die DB-Instance, um sicherzustellen, dass die aufbewahrten binären Protokolle nicht zu viel Speicherplatz beanspruchen. Bei Multi-AZ-DB-Cluster-Bereitstellungen können Sie die Aufbewahrung von Binärprotokollen nur über die Writer-DB-Instance konfigurieren und die Einstellung wird asynchron an alle Reader-DB-Instances weitergegeben. Wenn Binärprotokolle auf dem DB-Cluster die Hälfte des gesamten lokalen Speicherplatzes überschreiten, verschiebt Amazon RDS automatisch veraltete Protokolle auf das EBS-Volume. Die neuesten Protokolle verbleiben jedoch im lokalen Speicher, sodass sie verloren gehen können, wenn ein Fehler auftritt, der einen Host-Austausch erfordert, oder wenn Sie die Datenbank nach oben oder unten skalieren. #### Quellenverzögerung Verwenden Sie den Parameter `source delay` in einem Lesereplikat zur Angabe der Sekundenzahl, um die die Replikation vom Lesereplikat zur entsprechenden Quelldatenbank-Instance verzögert werden soll. Amazon RDS repliziert Änderungen normalerweise so schnell wie möglich, in einigen Umgebungen ist aber eine Verzögerung der Replikation sinnvoll. Wenn die Replikation verzögert wird, können Sie alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherstellen. Wenn eine Tabelle versehentlich entfernt wurde, können Sie sie aufgrund der verzögerten Replikation schnell wiederherstellen. Der Standardwert von `target delay` ist `0` (Replikation nicht verzögern). Wenn Sie diesen Parameter verwenden, wird [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) ausgeführt und „CHANGE primary TO MASTER\$1DELAY = input value“ angewendet. Bei Erfolg speichert die Prozedur den Parameter `source delay` in der Tabelle `mysql.rds_configuration`. Verwenden Sie zum Angeben der Anzahl der Sekunden für Amazon RDS, um die die Replikation in eine Quell-DB-Instance verzögert werden soll, die gespeicherte Prozedur `mysql.rds_set_configuration`. Im folgenden Beispiel wird die Replikation um mindestens eine Stunde (3 600 Sekunden) verzögert. `call mysql.rds_set_configuration('source delay', 3600);` Die Prozedur führt dann `mysql.rds_set_source_delay(3600)` aus. Die Obergrenze für den Parameter `source delay` beträgt einen Tag (86 400 Sekunden). #### target delay Verwenden Sie den Parameter `target delay` zur Angabe der Sekundenzahl, um die die Replikation zwischen einer DB-Instance und künftigen von RDS verwalteten Lesereplikaten, die anhand dieser Instance erstellt werden, verzögert werden soll. Dieser Parameter wird für non-RDS-managed Read Replicas ignoriert. Amazon RDS repliziert Änderungen normalerweise so schnell wie möglich, in einigen Umgebungen ist aber eine Verzögerung der Replikation sinnvoll. Wenn die Replikation verzögert wird, können Sie alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherstellen. Wenn eine Tabelle versehentlich entfernt wurde, können Sie sie mithilfe der verzögerten Replikation schnell wiederherstellen. Der Standardwert von `target delay` ist `0` (Replikation nicht verzögern). Für die Notfallwiederherstellung können Sie diesen Konfigurationsparameter mit der gespeicherten Prozedur [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) oder [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) verwenden. Um alle Änderungen bis zu einem Zeitpunkt unmittelbar vor Eintreten des Notfalls in einem verzögerten Lesereplikat wiederherzustellen, können Sie die Prozedur `mysql.rds_set_configuration` mit diesem Parametersatz ausführen. Nachdem die Prozedur `mysql.rds_start_replication_until` oder `mysql.rds_start_replication_until_gtid` die Replikation gestoppt hat, können Sie das Lesereplikat zur neuen primären DB-Instance hochstufen (siehe die Anleitung unter [Hochstufen eines Lesereplikats zur eigenständigen DB-Instance](USER_ReadRepl.Promote.md)). Um die Prozedur `mysql.rds_rds_start_replication_until_gtid` verwenden zu können, muss die GTID-basierte Replikation aktiviert sein. Wenn Sie eine bestimmte GTID-basierte Transaktion überspringen möchten, von der Sie wissen, dass sie einen Notfall verursacht, können Sie die gespeicherte Prozedur [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) verwenden. Weitere Informationen über das Arbeiten mit der GTID-basierten Replikation finden Sie unter [Verwenden der GTID-basierten Replikation](mysql-replication-gtid.md). Verwenden Sie zum Angeben der Anzahl der Sekunden für Amazon RDS, um die die Replikation in ein Lesereplikat verzögert werden soll, die gespeicherte Prozedur `mysql.rds_set_configuration`. Das folgende Beispiel gibt an, dass die Replikation um mindestens eine Stunde (3600 Sekunden) verzögert wird. `call mysql.rds_set_configuration('target delay', 3600);` Die Obergrenze für den Parameter `target delay` beträgt einen Tag (86 400 Sekunden). ## mysql.rds\$1show\$1configuration Die Anzahl der Stunden, während der binäre Protokolldateien aufbewahrt werden sollen. ### Syntax ``` CALL mysql.rds_show_configuration; ``` ### Nutzungshinweise Mit der gespeicherten Prozedur `mysql.rds_show_configuration` überprüfen Sie, wie viele Stunden Amazon RDS die binären Protokolldateien aufbewahrt werden. ### Beispiele Nachfolgend sehen Sie ein Beispiel für die Anzeige des Aufbewahrungszeitraums: ``` 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. ```