Hello,
MySQL 5.5. Van egy alkalmazás, ami évente előkerül: egy regisztrációs form egy eseményre.
A form korábbi éveinek regisztrációit archíválni szoktam (nem kezelünk személyes adatot...), pl
regform - ez a tábla neve
alter table regform rename regform_YYYYMMDD
alakban, majd ismét létrehozom a táblát:
create table regform ( ... ).
Így történt most is, 06.21-én, pénteken.
Ma elindult a regisztráció, és valaki jelzett, hogy nem tud regisztrálni, mert már regisztrálva van (egyedi kód). Megnéztem, és valóban - a két évvel ezelőtti, azaz a tavaly archívált tábla (regform_2018MMDD) adatai kerültek vissza. Ez a tábla szerepel már a szombat hajnali mentésben is, tehát aznap került vissza.
Az adatbázishoz másnak nincs hozzáférése, én péntek reggel adtam ki a create table parancsot, ami sikeresen le is futott.
Közben egy ügyfél jelzett, hogy az ő adatbázisában van egy tábla, ami fájlok leöltését logolja, és ő ezt naponta ki szokta pucolni, viszont a múlt héten azt vette észre, hogy visszakerülnek régi rekordok ebbe a táblába - kb a törlés után 10 perccel ismét megnézte, és ott voltak a rekordok ismét. Mivel évek óta így csinálja, nem hinném, hogy most 2 napra elfelejtette a PHPMyAdmin kezelését.
Vasárnap egyéb okból (akkor még ezek a hibák nem voltak ismertek) volt egy MySQL restart, előtte kb több, mint 1 éve futott a MySQL. Az ügyfél elmondása szerint hétfő reggel óta megszűnt a törölt rekordok visszamászása. A tábla visszaállást egyáltalán nem (sem) értem.
Logokban semmi, error.log-ban néhány ismétlődő (ismert) hiba (pl a MySQL adatok külön partíción vannak, és a lost+found könyvtárra pampog), syslogban semmi, slow.log-ban néhány tényleg kövér lekérdezés.
Van valakinek bármi ötlete, mi lehet(ett) ez?
update: az első esetben leírt tábla InnoDB formátumú, a második eset MyISAM.
Hozzászólások
Nincs véletlenül valami szinkronizáció két mysql szerver között ami szinkronizálja a táblákat, és valamiért törött az egyik irányba a szinkronizáció (így nem megy át az ALTER TABLE), viszont vissza irányba pedig működik, és ezért visszaszinkronizálja az adatokat?
Hello,
nincs, egyik esetben sincs.
De ha az első esetet (teljes tábla visszaállása) nézem, akkor a szinkronizációból miért a két évvel ezelőtti adatok (és csak azok) jöttek volna vissza, miért nem a tavalyiak?
a.
SUB
valami cronjob a hétvégén?
Semmi. Különösen olyan nem, ami archívált táblából tölt vissza production-be adatot :).
mi volt a pontos create table statement? nem lehet,hogy valami régi táblát használtál alapnak és onnan jöttek az adatok?
Az eljárás az volt, hogy MySQL Workbench-ben a táblára nyomtam egy alter table-t, ahol átneveztem magát a táblát. A művelet befejezésekor frissítettem a táblalistát, eltűnt a regform, és megjelent az archívált verzió (az idei...). Rányomtam arra jobb gombbal, ott "Copy create statemenent", beillesztettem a szerkesztő ablakba, átírtam a tábla nevét regform_YYYYMMDD formáról simán regform-ra, és lefuttattam.
Nem volt semmi INSERT INTO...
Utána még ellenőríztem ismét a táblalistát, és az újonann létrehozott táblát, az üres volt.
én sem mondtam, hogy insert volt. de ha azt mondod, hogy leellenőrizted, hogy biztosan üres volt a create után, akkor valami event/job lehetett a bűnös.
Ok, csak ezt nem értem akkor: valami régi táblát használtál alapnak és onnan jöttek az adatok.
create table regform(...) as select ... from regform_2018MMDD
erre gondoltam, ilyenkor ugye átjönnek az adatok a régi táblából.
Értem, de ennyire én nem vagyok bátor :).
Ennyi volt: "CREATE TABLE regform (...) ENGINE=InnoDB DEFAULT CHARSET=utf8;"
Tuti nincs valami trigger vagy event ami még basztathatja?
Vagy valahol egy UI ahol restore-olni lehet?
Tuti, hogy nincs trigger.
UI-ba meg nem teszünk ilyet :)
(Mármint ebben az esetben semmi nem indokolta - ketten csináltuk, évente 1x kell elővenni, leporolni... kézzel 20p az egész elindítása)
De most nem értem: az történt h csak az adatok másolódtak bele a régiből az újba? Pl. az első rekord mikori?
Mi az az egyedi kód? Egy unique index?
De most nem értem: az történt h csak az adatok másolódtak bele a régiből az újba?
* hidd el, nekem ez a csak már bőven sok
* nem tudom, hogy "bemásolódtak" az adatok (INSERT INTO table SELECT * FROM table_archive - amúgy ilyen értelemszerűen nincs sehol...), vagy mondjuk az InnoDB-n belül valahogy az egész tábla "újra létrejött".
Igen, az egyedi kód egy uniqe string, 10 v 12 karakteres, az alkalmazás állítja elő.
Némi szerencsével első körben a tábla tartalma alapján is eldönthető lenne a dolog. A "csak" arra vonatkozott, h nem mindegy h valami bemásolja a régi rekordokat, vagy időnként az egész táblát felülcseszi adatvesztést okozva!
auditd
Mármint visszamegyek az időben, beállítom, visszatérek, és hopp: meg tudom nézni!
:D
Azt hittem ez egy re-occuring event. Godoltam beallitod es legkozelebb tudod mi tortent. De akkor nem ertettem meg. Bocs.
Nem, ha visszatérő eset lenne, már valszeg valahogy elkaptam volna - de sajnos ez most elég egyedi. :(
Semmi gond - köszi az ötleteket :).
Guess:
Két évvel ezelőt kellet hackelni valamit az appon és bent maradt valami a kódban? :)
Lehet, de akkor valamit elszúrtunk két éve, mert tavaly nem másolódott át a 3 évvel ezelőtti archív :).
Amúgy értelemszerűen nincs ilyen kód/bugfix/hack, eleve rohadt macerás lenne (jó, annyira nem :)), mert változik az indulási időszak, ezáltal az archíválás is. Márciustól talán júliusig volt, ami eddig előfordult.
Balga kerdes, de nincs veletlenul overlay filesystem? MyISAM esetén érthető is lenne, de InnoDB -t ez sem magyarázza.
Esetleg valami rollback metodus? binlog van? abbol vissza lehetne jatszani, mi tortent.
Nem balga kérdés, és de: LVM-en vannak az adatok (igazából majdnem minden LVM-en van).
De amúgy mit magyarázna ez?
Nincs rollback (MyISAM-nál ez eleve nem releváns), ahogy fentebb írtam, Workbench-ben csináltam, szerintem ott az alter table nem tranzakción belül van, és a create table sem. Ill gondolom ha valamilyen csoda folytán mégis így történt volna, akkor az új session-ben a tábla nem lett volna üres.
Nincs binlog :(.
Azért kérdezi, hogy nem lehet e hogy fs/blockdevice szinten történt valami, amitől régebbi állapotot kezdett el látni.
Mondjuk failover egy régi állapotot tartalmazó NAS/SAN/akármire.
Nincs semmi failover megoldás, annyira nem business-critical. Napi egy mentés van, SSHFS egy másik gépre, és csak oda történik a dump. De ahogy írtam, a mentésben már ez van benne.
és ha megismétled a teljes procedúrát, ezúttal bekapcsolt binlog-gal? legalább kiderülne, hogy mi történt.
Ma megismételtem - igaz, binlog nélkül.
Egyelőre nem mászott vissza semmi :). Elindultak a regisztrációk, ezt most picit békén kell hagyni.
Nekem amúgy valami InnoDB bug a gyanúm... valamit cache-elt, és visszatette... és a vasárnapi restart meg helyretette az egész MySQL-t.
Lehet atsiklottam felette, de masik db-k/tablak is vannak a mysql-ben, azok nem valtoztak?
Ha esetleg ez az 1 van benne vagy tobbi is valtozott akkor nem lehet hogy lvm snapshot keszult 2 eve ami azota ottmaradt, mostanra meg elfogyott a hely es eldobta az a snapshotot ezzel visszaallva a korabbi adatokra?
Vannak más DB-k is, de azokról egyelőre nem derült ki semmi - pont ez az, ami aggaszt...
Amúgy két táblával történt ez, a regformhoz kapcsolódik egy tábla (normalizált adatok - egy regisztrációhoz több regisztrálandó objektum tartozik), és az úgyanúgy "visszaállt". Mindkettő InnoDB.
Más anomáliáról nem tudok (sem más adatbázis, sem másik tábla ezen a DB-n belül, pedig van még egy, ami ugyanígy archíválva lett - az MyISAM, és a renddezvényhez kapcsolódó választható elemek vannak benne, azt nem írja semmi).
(Mindenkitől bocsánat, ez menet közben derült még ki, nem tudtam megírni még.)
Itt nem használok LVM snapshot-ot.