Soms zijn we uitgeput door een lange dag en maken we fouten, wat uiteindelijk het hele team veel tijd kost.
Gisteren testte ik verschillende back-up- en herstelmethoden die worden ondersteund door ZRM, een MySQL-back-upservice voor een aanstaande release. ZRM voor MySQL vereist dat binaire logboekregistratie is ingeschakeld op de MySQL-server. Ik had geen schijfruimte meer tijdens het testen en verwijderde de binaire logboeken.
Per ongeluk heb ik het laatste binaire logboek verwijderd dat door de MySQL-server werd gebruikt en MySQL-server gebruikt het meest recente binaire logboek om zijn daemon uit te voeren.
Korte versie - Ik kon de MySQL-server helemaal niet starten.
Herstel binaire MySQL-logboeken: stacktracering bij het starten van de server
$ service mysqld start
061031 17:38:48 mysqld gestart
061031 17:38:48 InnoDB: gestart; log-volgnummer 14 1645228884
/ usr / libexec / mysqld: bestand '/var/lib/mysql/mysql-bin.000017' niet gevonden (foutcode: 2)
061031 17:38:48 [FOUT] Kan logboek niet openen (bestand '/var/lib/mysql/mysql-bin.000017', fout 2)
061031 17:38:48 [FOUT] Kan logbestand niet openen
061031 17:38:48 [FOUT] Kan tc-log niet starten
061031 17:38:48 [FOUT] Afbreken
061031 17:38:48 InnoDB: afsluiten starten ...
061031 17:38:51 InnoDB: Afsluiten voltooid; logboekvolgnummer 14 1645228884
061031 17:38:51 [Note] / usr / libexec / mysqld: Afsluiten voltooid
061031 17:38:51 mysqld eindigde
Met dank aan Aishwarya voor het geven van ideeën om het probleem op te lossen. Het binaire logboekindexbestand (/var/lib/mysql/mysql-bin.index) slaat informatie op over het meest recente binaire logboekbestand. Het verwijderen van het indexbestand lost het probleem op. Natuurlijk had ik back-ups van de database met behulp van ZRM voor MySQL en kon ik herstellen tot elk moment voordat het binaire logboek werd verwijderd.
Kort gezegd: verwijder het meest recente binaire logbestand niet om schijfruimte te besparen en maak regelmatig back-ups. ZRM heeft de voorkeur en hier is een link voor meer informatie