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.
- 1460 megtekintés
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
SUB
- A hozzászóláshoz be kell jelentkezni
valami cronjob a hétvégén?
- A hozzászóláshoz be kell jelentkezni
Semmi. Különösen olyan nem, ami archívált táblából tölt vissza production-be adatot :).
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
é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.
- A hozzászóláshoz be kell jelentkezni
Ok, csak ezt nem értem akkor: valami régi táblát használtál alapnak és onnan jöttek az adatok.
- A hozzászóláshoz be kell jelentkezni
create table regform(...) as select ... from regform_2018MMDD
erre gondoltam, ilyenkor ugye átjönnek az adatok a régi táblából.
- A hozzászóláshoz be kell jelentkezni
Értem, de ennyire én nem vagyok bátor :).
Ennyi volt: "CREATE TABLE regform (...) ENGINE=InnoDB DEFAULT CHARSET=utf8;"
- A hozzászóláshoz be kell jelentkezni
Tuti nincs valami trigger vagy event ami még basztathatja?
Vagy valahol egy UI ahol restore-olni lehet?
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
auditd
- A hozzászóláshoz be kell jelentkezni
Mármint visszamegyek az időben, beállítom, visszatérek, és hopp: meg tudom nézni!
:D
- A hozzászóláshoz be kell jelentkezni
Azt hittem ez egy re-occuring event. Godoltam beallitod es legkozelebb tudod mi tortent. De akkor nem ertettem meg. Bocs.
- A hozzászóláshoz be kell jelentkezni
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 :).
- A hozzászóláshoz be kell jelentkezni
Guess:
Két évvel ezelőt kellet hackelni valamit az appon és bent maradt valami a kódban? :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :(.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
és ha megismétled a teljes procedúrát, ezúttal bekapcsolt binlog-gal? legalább kiderülne, hogy mi történt.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni