MySQL - törölt adatok visszakerülnek

Adatbázis: SQL, XML DB

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

( hunti v | 2019. 06. 25., k – 11:48 )

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?

( nydn | 2019. 06. 25., k – 12:19 )

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.

( BehringerZoltan | 2019. 06. 25., k – 12:36 )

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ő.

( fhuse | 2019. 06. 25., k – 13:07 )

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.

( wladek1 | 2019. 06. 25., k – 13:30 )

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 :(.

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.