Crash-Recovery
MySQL Server unterstützt Crash-Recovery, das Dauerhaftigkeit sicherstellt und bei einem unerwarteten Beenden des Servers ein Daten-Recovery ermöglicht.
Während diese Redundanz beim normalen Betrieb des Servers vorteilhaft ist, kann sie die Performance bei großen Datenimporten reduzieren. Sie können die Crash-Recovery-Prozesse vorübergehend deaktivieren, sodass Sie DML-Anweisungen ohne Synchronisierungs-Overhead ausführen können.
Hinweis
Wenn eine Komponente eines Standalone-DB-Systems ausfällt, während das Crash Recovery deaktiviert ist, geht das DB-System in den Status
Wenn eine Komponente eines Standalone-DB-Systems ausfällt, während das Crash Recovery deaktiviert ist, geht das DB-System in den Status
FAILED über und kann nicht wiederhergestellt werden. Es wird empfohlen, vor dem Deaktivieren des Crash-Recoverys ein vollständiges manuelles Backup auszuführen. Hoch verfügbare DB-Systeme in Multi-Availability-Domains sind eher fehlerresistent, aber unter bestimmten Umständen können sie auch nicht wiederhergestellt werden.
Wenn Sie das Crash-Recovery deaktivieren, wird Folgendes deaktiviert:
- InnoDB Redo-Log
- Doublewrite-Puffer
- Binärlogsynchronisierung
Wenn Sie Crash-Recovery deaktivieren, können Sie die folgenden HeatWave-Serviceprozesse nicht verwenden:
- Backups (manuell und automatisch)
- Stopp und Neustarten des DB-Systems
Hinweis
Es wird nicht empfohlen, ein DB-System ohne Crash Recovery auszuführen, außer wenn große Datenimporte ausgeführt werden.
Es wird nicht empfohlen, ein DB-System ohne Crash Recovery auszuführen, außer wenn große Datenimporte ausgeführt werden.
Wenn das Crash Recovery zu Beginn eines Upgradevorgangs für das DB-System deaktiviert ist, wird es für die Dauer des Upgradeprozesses erneut aktiviert und nach Abschluss des Upgrades wieder deaktiviert. Gleiches gilt für einen Failover von der primären zu einer sekundären Instanz eines hoch verfügbaren DB-Systems. Wenn der Hochstufungsprozess abgeschlossen ist, wird das Crash-Recovery wieder deaktiviert.