Det finns tillfällen när vi är utmattade på grund av en lång dag och vi slutar göra misstag, vilket slutligen kostar hela laget mycket tid.
Igår testade jag olika backup- och återställningsmetoder som stöds av ZRM, en MySQL-säkerhetskopieringstjänst för en kommande release. ZRM för MySQL kräver binär loggning för att vara aktiverad på MySQL-servern. Jag fick slut på diskutrymme under testningen och tog bort de binära loggarna.
Av misstag raderade jag den senaste binära loggen som användes av MySQL-servern och MySQL-servern använder den senaste binära loggen för att köra sin demon.
Kort version - Jag kunde inte starta MySQL-servern alls.
Återställ MySQL-binära loggar: Stack spårning när du försöker starta servern
$ service mysqld start
061031 17:38:48 mysqld startade
061031 17:38:48 InnoDB: Startade; loggsekvensnummer 14 1645228884
/ usr / libexec / mysqld: Fil '/var/lib/mysql/mysql-bin.000017' hittades inte (felkod: 2)
061031 17:38:48 [FEL] Det gick inte att öppna loggen (fil '/var/lib/mysql/mysql-bin.000017', errno 2)
061031 17:38:48 [FEL] Det gick inte att öppna loggfilen
061031 17:38:48 [FEL] Det går inte att initiera tc-loggen
061031 17:38:48 [FEL] Avbryter
061031 17:38:48 InnoDB: Startar avstängning ...
061031 17:38:51 InnoDB: Avstängning slutförd; loggsekvensnummer 14 1645228884
061031 17:38:51 [Obs] / usr / libexec / mysqld: Avstängningen slutförd
061031 17:38:51 mysqld slutade
Tack till Aishwarya för att ge mig idéer om hur jag kan lösa problemet. Den binära loggfilen (/var/lib/mysql/mysql-bin.index) lagrar information om den senaste binära loggfilen. Att radera indexfilen löser problemet. Naturligtvis hade jag säkerhetskopior av databasen med ZRM för MySQL och jag kunde återhämta mig till vilken tidpunkt som helst innan den binära loggen raderades.
Slutsats: Ta inte bort den senaste binära loggfilen för att spara diskutrymme och göra vanliga säkerhetskopior. ZRM är att föredra och här är en länk för mer information
