it-swarm-eu.dev

Lepší cesta z logu MySQL InnoDB „v budoucnosti“?

Tuto chybu InnoDB mám v MySQL 5.0. Mysqld byl čistě zastaven, ale později se mi podařilo ztratit ib_logfile0 a ib_logfile1. Nyní po čistém spuštění InnoDB provedl „zotavení po havárii“. Prošel jsem obchodem innodb_force_recovery = 4, opravil zavěšený MyISAM stůl a nyní je replikace připravena jít, kromě toho. Velká čísla potvrzena:

111116 15:49:36  InnoDB: Error: page 393457 log sequence number 111 561,760,232
InnoDB: is in the future! Current system log sequence number 70 3,946,969,851.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: for more information.

Toto je na podřízeném serveru. Výše uvedená chyba se šíří stovkami. Našel jsem tuto odpověď: „vložte a smažte> 64 GB dat, aby se pořadové číslo protokolu dostatečně nafouklo“.

http://forums.mysql.com/read.php?22,50163,50163#msg-50163

Toto kouzelné číslo 64 GB pochází ze 4 GB * 16, kde je potřeba zvýšit počet logodin „hlavního čísla“ tohoto chlapa z 0 na 15. Důl jde ze 70 na 111 = 164 GB. Bude to trvat 5 dní. Budu dál pracovat na urychlení mého skriptu a paralelním spuštěním, abych to urychlil. Mezitím doufám, že někdo jiný má lepší odpověď. To je hloupé.

16
IcarusNM

To byla docela vzácná situace. Doufám, že už nikdy nekončím, s InnoDB "log pořadové číslo je v budoucnu!" chyba. Z důvodu mých konkrétních podrobností byla přestavba/obnova dat na mém serveru poslední možností. Některé podvody v pomoci, které byly dobré nápady, ale nakonec jsem se rozhodl jen vylepšovat svůj skript v Perlu, abych hrál tuto hloupou hru a proletěl tolik koncertů za hodinu, kolik jsem mohl. Co to sakra je, je to dobrý zátěžový test systému.

Nezapomeňte: cílem je zvýšit jeden čítač ("pořadové číslo protokolu"), který je uložen někde v záhlaví ib_logfile a ib_logfile1. Tím se InnoDB podvádí, takže bude ignorovat zjevnou časovou deformaci a pokračovat v životě. Ale nikdo neví, jak toto číslo upravit. Nebo pokud to vědí, nikdo nemluví.

Tady je můj finální produkt. YMMV, ale použití funkce REPEAT mysql pro interní generování dat je vysoce efektivní.

 #!/usr/bin/Perl
 use DBI;
 $table = shift || die;
 $dbh = DBI->connect("DBI:mysql:junk:Host=localhost", "user", "pass"); #Edit "junk" (DB name), user, and pass to suit.
 $dbh->do("DROP TABLE IF EXISTS $table");
 $dbh->do("CREATE TABLE $table (str TEXT) ENGINE=INNODB");
 $sth = $dbh->prepare("INSERT INTO $table (str) VALUES (REPEAT(?,1000000))");
 foreach (1..50) {
    $sth->execute('0123456789');   # 10 MB
 }
 $dbh->do("DELETE FROM $table");

Můj doporučený recept:

  1. Vytvořte „nevyžádanou“ databázi
  2. Uložte výše uvedený skript Perl jako junk.pl.
  3. Spusťte junk.pl data1 a junk.pl data2 a junk.pl data atd. Najednou, pro tolik jader CPU jako váš databázový server, začít. Otevřete více nábojů a zabalte každý cyklus do smyčky Bash: while true; do date; junk.pl dataX; done.

Sledujte, jak vaše LSN roste, možná v jiné smyčce:

 silly# echo "SHOW INNODB STATUS \G" | mysql -p'xxxxxx' | grep '^Log seq'
 Log sequence number 124 3871092821
 silly# echo "SHOW INNODB STATUS \G" | mysql -p'xxxxxx' | grep '^Log seq'
 Log sequence number 124 4209892586
 silly# echo "SHOW INNODB STATUS \G" | mysql -p'xxxxxx' | grep '^Log seq'
 Log sequence number 125 85212387

Velké číslo je nepodepsaný 32bitový INT, který se zabalí na 4 GB, přičemž se vždy zvýší menší číslo. V tomto případě výše se to rozbalilo ze 124 na 125. Váš cíl je skryt v mysqld.log, který vám poslal Googling za toto směšné řešení. Jakmile překročíte tuto cílovou čáru, je to! Vyhodit rohy! Uvolněte konfety!

Postranní panel: Tímto se odhalila zajímavá chyba v mysqld 5.0 w/REPEAT: pokud přejdete na 20 MB, převrátí se interní čítač a převrátí se na ~ 96 KB. Žádné varování ani chyba nikde. Nechtěl jsem to ztrácet čas sledováním. 10 MB funguje skvěle. Pokud zasáhnete nějaký jiný limit, může si stěžovat. Mám různé innodb vyrovnávací paměti zvýšené od výchozího nastavení. Ochutnejte sezónu. Jako vždy sledujte mysqld.log v jednom okně.

10
IcarusNM

Máte tři (3) možnosti:

MOŽNOST 01: Proveďte rsync Master-Slave (prostoje na Master)

  • Krok 01: Spustit reset master; na master (Zaps Binary Logs)
  • Krok 02: service mysql stop na masteru
  • Krok 03: service mysql stop na otroka
  • Krok 04: rsync/var/lib/mysql z masteru na slave
  • Krok 05: service mysql start na masteru
  • Krok 06: Použijte první binární protokol na hlavním serveru jako protokol pro spuštění replikace. Jako pozici pro zahájení replikace použijte velikost souboru tohoto protokolu
  • Krok 07: service mysql stop --skip-slave-start na otroka
  • Krok 08: Spusťte příkaz CHANGE MASTER TO pro nastavení replikace z protokolu a pozice zjištěné v kroku 06
  • Krok 09: Spustit start slave; na slave a nechte replikaci dohonit

MOŽNOST 02: Proveďte rsync Master-Slave (minimální prostoje na Master)

  • Krok 01: Spustit reset master; na master (Zaps Binary Logs)
  • Krok 02: service mysql stop na otroka
  • Krok 03: rsync/var/lib/mysql od pána k otroku
  • Krok 04: Opakujte krok 03, dokud dva po sobě následující rsyncs nezabírají stejné množství času
  • Krok 05: service mysql stop na masteru
  • Krok 06: rsync/var/lib/mysql od pána k otroku
  • Krok 07: service mysql start na masteru
  • Krok 08: Použijte první binární protokol na hlavním počítači jako protokol pro spuštění replikace. Jako pozici pro zahájení replikace použijte velikost souboru tohoto protokolu
  • Krok 09: service mysql stop --skip-slave-start na otroka
  • Krok 10: Spusťte příkaz CHANGE MASTER TO pro nastavení replikace z protokolu a pozice zjištěné v kroku 08
  • Krok 11: Spustit start slave; na slave a nechte replikaci dohonit

MOŽNOST 03: Použijte XtraBackup

Tento softwarový nástroj nejen vytvoří nevtíravou kopii běžícího masteru, ale také vytvoří odpovídající ib_logfiles pro vás. Budete muset nastavit replikaci

Zveřejnil jsem na StackExchange dříve na toto téma

Tyto věci jsem udělal mnohokrát pro webhostingovou společnost mého zaměstnavatele. Jeden klient měl přesunout 3,7 TB a trvalo to asi 16 hodin. 64 GB je ve srovnání velmi malé.

5
RolandoMySQLDBA

Zjistil jsem, že existuje snad chladnější způsob, jak tento problém vyřešit pomocí dělících tabulek. Z některých let jsem musel zrušit oddíly a pro rok 2014 jsem je musel přidat. Téměř všechny oddíly hlásí tuto chybu, tedy i staré. Velmi ošklivá havárie.

Takže zatímco DROPPING staré a pomocí REORGANIZE oddílu MAXVALUE (poslední), vytvoří nové soubory, které jsou v pořádku, takže dostávám méně a méně varování. Mezitím to pomůže inkrementovat čítač sekvencí protokolu, takže nemusím vkládat falešná data. Dělám to na hlavním serveru btw ...

Takže tohle:

ALTER TABLE Events DROP PARTITION p1530 , p1535 , p1540 , p1545 , 
p1550, p1555 , p1560 , p1565 , p1570 , p1575 , p1580 , p1585 , p1590 , 
p1595 , p1600 , p1605 , p1610 , p1615 , p1620 , p1625 , p1630 , p1635 , 
p1640 , p1645 , p1650 , p1655 , p1660 , p1665 , p1670 , p1675 , p1680 , 
p1685 , p1690 , p1695 , p1700 , p1705 , p1710 , p1715 , p1720 , p1725 , 
p1730 , p1735 , p1740 , p1745 , p1750 , p1755 , p1760 , p1765 , p1770 , 
p1775 , p1780 , p1785 , p1790 , p1795 , p1800 , p1805 , p1810 , p1815 , 
p1820 , p1825 , p1830 , p1835 , p1840;

A tohle:

ALTER table Events REORGANIZE PARTITION p3000 INTO (
PARTITION p3500 VALUES LESS THAN (TO_DAYS('2013-01-01')),
PARTITION p3510 VALUES LESS THAN (TO_DAYS('2013-01-04')),
PARTITION p3520 VALUES LESS THAN (TO_DAYS('2013-01-07')),
PARTITION p3530 VALUES LESS THAN (TO_DAYS('2013-01-10'))
...
PARTITION p4740 VALUES LESS THAN (TO_DAYS('2014-01-08')),
PARTITION p9000 VALUES LESS THAN MAXVALUE)

To účinně zahodí každý oddíl ve změně a znovu jej vytvoří s dočasnou kopií obsahu toho, co tam bylo. Můžete to udělat podle tabulky, pokud chcete, moje aplikace to umožňuje, takže se nemusíte starat o synchronizované zálohy atd.

Nyní pro zbytek tabulky, protože jsem se nedotkl všech oddílů v procesu, některé zůstanou s upozorněním na sekvenci protokolu, pro ty, které jsou zlomené, ale pokryté touto reorganizací akce, kterou pravděpodobně spustím:

ALTER TABLE Events REBUILD PARTITION p0, p1;

nebo tak

ALTER TABLE Events OPTIMIZE PARTITION p0, p1;

Takže, to mě přimělo přemýšlet, Dalo by se to udělat pomocí obyčejných vanilkových tabulek, dočasně přidat oddíly pomocí hash a později je odstranit (nebo je nechat, mohu důrazně doporučit oddíly).

Používám mariadb, ne mysql (takže XtraDB)

Možná to někomu pomůže. Stále to běžím, tak dobře. Zdá se, že změna ENGINE také vykonává tuto práci, takže ji přivedu tam a zpět mezi MyIsamem a zpět do InnoDB.

Je to docela logické, pokud změníte motor, tabulka zmizí z innodb, takže to už nebude problém.

ALTER TABLE Events ENGINE=MyISAM;
ALTER TABLE Events ENGINE=InnoDB;

zdá se, že to tady funguje. Na tabulkách s oddíly mohu potvrdit několik věcí:

  • ALTER TABLE xyz ENGINE = InnoDB je velmi pomalý, k Arii (mariadb) dvakrát tak rychle, ale obecně je to pomalý způsob, jak zvýšit čítač log sekvencí
  • ALTER TABLE xyz REBUILD PARTITION ALL je nejrychlejší způsob, jak 'opravit' tabulky a pomoci zvýšit čítač
  • ALTER TABLE xyz ANALYZE PARTITION ALL je pomalá ve srovnání s bývalým a nepřepisuje oddíly, u kterých se zdá, že jsou v pořádku. REBUILD zajišťuje přepis do schématu dočasné tabulky.

Poslední jsem použil na několika stolech. Varování se objeví, když se pokouší otevřít soubory a existuje jedno pro každou definici oddílu, která se otevře s problémy s čítačem. Téměř se převalil přes přepážku pro poslední tabulky. Myslím, že jakmile je vše zpracováno, je třeba vyprázdnit binární protokoly.

pdate: Mohu uzavřít několik věcí, nyní se mi tento problém podařilo vyřešit.

  • Moje havárie byla způsobena reorganizací oddílů na stole ve formátu Aria (MariaDB).
  • (pro mě) provedení přestavby oddílů fungovalo nejlépe a nejrychleji, aby se počitadlo sekvencí posunulo nahoru. Změna motoru je pomalá a musíte to udělat dvakrát, abyste ovlivnili inodb. změna na innoDB je poměrně pomalá ve srovnání s MyIsamem nebo Arií.
  • Upgradoval jsem na MariaDB 5.3 a ne na 5.5 (byl: 5.2) a funguje to dobře. Myslím, že existuje příliš mnoho problémů s árií, oddíly v 5.5 (a potvrzené chyby), které by tuto kombinaci používaly.
  • Opravdu by měl existovat lepší způsob, jak resetovat čítač sekvencí protokolů.
2
Glenn Plas