"Even" een nieuwe MySQL replica
Replication is een soort sociale constructie waarbij er 1 master database is en 1 of meer slaves die alle wijzigingen in de master database meenemen. Hierdoor heb je 1 centrale plek om wijzigingen door te voeren (master) en kun je de data lezen van welke slave je wilt. Hoe meer slaves, hoe meer (lees)queries per seconde je uit kan voeren omdat ze verdeeld kunnen worden over alle slaves.
Nou, op het werk was er dus zo'n slave uitgevallen. Hierdoor kregen de overgebleven (1) slaves het allemaal erg druk. Diagnose: verdachte storage controller + fried drives. Zelfs het welbekende SATA commando "wakker worden bitch" werd door elke drive met stilte beantwoord. Prima, nu even niks aan te doen (we hadden geen reserveonderdelen), dus dan maar een andere server reeds in het datacenter ombouwen tot slave. We hebben een stuk of tig webservers die eigenlijk stiekem toch best wel erg overpowered zijn, daar kon ik best wel eentje van gebruiken. Dus, uit de Apache loadbalancer, sudo systemctl stop apache2, even het ip ombouwen naar wat ooit het ip was van de nu dooie database slave (dit deel ging niet helemaal lekker en ging gepaard met een vlug ritje naar het datacenter). Oh ja, de database nog.
Kopietje in real time van de master trekken met mysqldump -e --skip-quick --no-autocommit --single-transaction --extended-insert --disable-keys --master-data=1 --include-master-host-port --all-databases | gzip > dump.sql.gz oftewel "alle data + binlog shit (slave config) + niet alle shit locken zodat de server dood gaat, eikel + etc" en dat dan mooi gezipt en gecomprimeerd. De dump downlooien naar de nieuwe slave en sudo mysql < zcat dump.sql.gz om de boel in te laaien. start slave werkte alleen niet, want blijkbaar stelt --master-data=1 --include-master-host-port nog steeds niet in welke host/port/user hij moet gebruiken, alleen binlog zooi. Dat was makkelijk genoeg te verhelpen door het CHANGE MASTER TO statement in de dump te amenderen. Ik vind nog steeds dat het niet zou moeten hoeven maar goed. Alles ok, dacht ik!
Tot er vreemde errors verschenen in onze centrale logging monitor bak dinges.
In "dingen die je liever niet leest": Jul 26 12:20:09 server php: [ERROR] [127.0.0.1] (mysqlQueryPdo) A Gorilla destroyed our database. Database connect error occurred; /www/script.php:mysqlQueryPdo; Database handler error. Errorcode: HY000; Driver errorcode: 1805; Error message: Column count of mysql.proc is wrong. Expected 21, found 20. The table is probably corrupted.
Ok nouja weet je prima kan gebeuren enzo: daar heb je mysql_upgrade voor. Dus ik doe dat, werkt niet, doe het nog een keer op alle db servers, werkt nog niet. Kut! Was het dan toch een gorilla?
Nee! Nee het was geen gorilla! Wat de fuck blijkt nou? mysqldump dumpt uit zichzelf niet de stored procedures! Waarom zou je dat willen? Wie de fuck gebruikt er nou stored procedures? Wtf zijn "stored procedures" überhaupt?? Vandaar dus dat die proc table ook niet klopte, daar horen die stored procedures in te staan! Dus, snel van de master even de stored procedures nog erachteraangegooid: mysqldump --routines --no-create-info --no-data --no-create-db --skip-opt --all-databases > proc.sql en toen werkte het weer. Ik haat mijn levenMooi!