Truncate ongedaan maken
Ik heb zonder back-up mijn (alle!) tabellen ge-truncate, dit was ook de bedoeling omdat ik een schone DB wilden.
Twee tabellen mochten echter niet geleegd worden ?
Kan ik vanuit DirectAdmin een DB herstel doen / afterimage naar een uur terug ?
Grt,
Bas
Ik hoop dat jij of je hosting ergens nog backups heeft, en die vrij wilt stellen.
Het kost je (in dit geval mij) toch een werkdag.
Ik draai zelf in Directadmin (op Admin-niveau) elke nacht een backup naar een externe server via de DA API. Maar dat kan natuurlijk ook op User niveau.
Gewijzigd op 28/10/2016 17:39:18 door - Ariën -
In MySQL is het ook nog eens gevaarlijk omdat het een impliciete COMMIT doet.
Dus als je iets doet als:
BEGIN;
TRUNCATE foo;
TRUNCATE bar;
TRUNCATE mary;
ROLLBACK;
dan zal de truncate van tabel 'bar' de transactie committen en daarmee is 'foo' vor eeuwig weg, ookal staat er verderop dus een ROLLBACK.
MySQL heeft meer van dit soort levensgevaarlijke fouten die niemand weet tot ze op een dag hun halve database kwijt zijn...
Gewijzigd op 28/10/2016 18:04:29 door bas hooff
Qua incrementele backups is er maar één optie en dat is een "binary log". Dat is een log waarin wordt vastgelegd wat er precies door elke query in de tabellen wordt veranderd. Groot voordeel daarvan is dat je b.v. elke dag een basis-backup kunt maken en dan de rest van de dag alleen de wijzigingen noteert. Gaat er iets stuk dan kun je de basisbackup vna die dag terugzetten en dan vannuit het binary log de veranderingen van die dag doorvoeren tot vlak voor het moment dat het stuk ging.
Echter, dat eist een ijzeren discipline qua het maken van bsisbackups en de binary logs, je *MOET* een recente basisbackup hebben en je moet alle logs vanaf die basisbackup tot het moment van falen hebben.
Je kunt ook niet de veranderingen van na de fout terugzetten, want die zijn afhankelijk van de situatie zoals hij was nadat de fout gemaakt was. Echt versiebeheer zoals in GIT en SVN gaat dus ook niet omdat tabellen onderling afhankelijk zijn.
Pg Vincent op 28/10/2016 17:58:46:
De impliciete COMMIT is geen gevaarlijke fout in MySQL, het is maar net hoe je MySQL configureert en met name welk database engine je configureert. Enne "levensgevaarlijke fouten" is dat niet een beetje kort door de bocht ??In MySQL is het ook nog eens gevaarlijk omdat het een impliciete COMMIT doet.
MySQL heeft meer van dit soort levensgevaarlijke fouten die niemand weet tot ze op een dag hun halve database kwijt zijn...
MySQL heeft meer van dit soort levensgevaarlijke fouten die niemand weet tot ze op een dag hun halve database kwijt zijn...
Truncate is bijna altijd definitief. Alleen wanneer je met transactions werkt kan truncate in bepaalde gevallen met rollback teruggedraaid worden (SQLserver en Postgres). Dit geldt niet voor alle database enigines. In MySQL en Oracle is truncate bijvoorbeeld altijd onherroepelijk en dat is conform SQL-2008 standaards. Truncate is namelijk DDL en geen DML.
Gewijzigd op 30/10/2016 22:21:30 door Aad B
Quote:
De impliciete COMMIT is geen gevaarlijke fout in MySQL, het is maar net hoe je MySQL configureert en met name welk database engine je configureert. Enne "levensgevaarlijke fouten" is dat niet een beetje kort door de bocht ??
Dat het configureerbaar is en afhankelijk van de engine is zo mogelijk een groter probleem dan het gedrag zelf. MySQL's gedrag kan verschillen per implementatie. Niet alleen per versie of engine, maar per implementatie. Hoe de database zich bedraagt hangt af van hoe de pet van de beheerder staat, en als je een applicatie voor een derde schrijft moet je feitelijk een lijst meegeven met instellingen voor de server, niet om de performance te halen of beveiliging te garanderen, maar gewoon om te zorgen dat je applicatie blijft werken...
En ja, levensgevaarlijk, voor je data in ieder geval. (Ik hoop dat er geen bedrijven zijn die MySQL gebruiken voor data die *echt* belangrijk is).
Voorbeeldje; Onlangs probeerde ik een password te resetten via ALTER USER, wat opzich niet vreemd is, toch? Maar toen kwam ik dit tegen in de handleiding:
"ALTER USER was added in MySQL 5.6.6. However, in 5.6.6, ALTER USER also sets the Password column to the empty string, so do not use this statement until 5.6.7."
Ze wisten dat alter-user zonder te vragen het wachtwoord aanpaste, en toch hebben ze het vrijgegeven.
Dus ja, "levensgevaarlijk" is nog niet eens zo'n overdreven term voor het soort fouten dat MySQL bevat.
Afijn, ik heb mijn zegje gezegd, ik ga er verder niet over door want dat levert toch alleen maar poep op.
Laat de conclusie voorlopig zijn dat je TRUNCATE alleen moet gebruiken als je 100% zeker bent dat de data weg mag, en dat je altijd moet zorgen dat je goede backups hebt voordat je data gaat weggooien (al is het maar voor als je een tikfout maakt en de verkeerde tabel leegt)
Pg Vincent op 31/10/2016 09:36:27:
Ik heb me voorgenomen om mijn tijd niet meer te verdoen aan MySQL bashing omdat men er blijkbaar toch niets van leert, maar ik wil dit wel even toelichten omdat het anders van mijn kant wel erg ongefundeerd klinkt....
Quote:
Vervolgens ga je er rustig mee door. Helaas heb je te weinig kennis om er echt serieus iets over te zeggen, helaas. Ik heb drie jaar met EnterpriseDB (Postgres) gewerkt na vele jaren Oracle. Ik kan je vertellen dat EnterpriseDB nog lang niet volwassen is maar ik zie geen enkele reden om maar doorlopend Progres of MySQL te bashen. Het zou je sieren om MySQL beheerders wat opbouwende tips te geven in plaats van te bashen. Vertel ze hoe ze het op moeten lossen zonder te migreren naar Progress of stop echt met commentaar leveren op MySQL. Zowel MySQL als Postgres zijn goedkope open source initiatieven voor duurdere gelicenseerde Database Engines zoals Oracle en zowel Postgres als MySQL hebben met name door hun open source karakter nog wat risico's voor toepassing. Maar in geen enkel geval is er sprake van "levensgevaarlijke fouten" zoals jij stelt. Wel mag geconstateerd worden dat MySQL voornamelijk door ondeskundige hosters wordt beheerd en dat er gemiddeld veel te weinig kennis is bij php developers vwb de ins en outs van database engines. Doorgaans wordt het "as is" gebruikt.
Gewijzigd op 31/10/2016 10:28:28 door Aad B
Afijn, dit is het soort poep dat ik bedoel, en waar ik geen zin meer in heb.
Een jaar of wat ben ik van PHPHulp af gegaan om precies dit soort gezeik en het blijkt nog net zo erg te zijn.
Veel plezier verder!
De kritiek wordt gegeven op semantisch vlak, en die semantiek heeft alles te maken met hoe belangrijk je data voor je is. Ook wordt EnterpriseDB aangehaald, en ik snap niet helemaal wat het punt daar is. Leuk, je hebt met EnterpriseDB gewerkt. Heb je ook met een *echte* PostgreSQL installatie gewerkt?
Alvorens in een welles-nietes discussie (al of niet gerechtvaardigd) te vervallen, is het wel zo netjes om even te vragen of de vraagsteller inmiddels antwoord heeft op zijn vraag
@bas hooff: is je vraag beantwoord?
Wat betreft de databases ... voer de discussie a.u.b. netjes zonder te jij-bakken. Door elkaar verwijten te maken en het spelletje "ik heb gelijk en jij niet" te gaan spelen, krijg je een vertroebelde discussie waar niemand bij gebaat is. Beter gewoon op een neutrale manier de voors en tegens opsommen, dan blijft het een beetje gezellig ;-)
(PS @John ... die laatste opmerking is niet helemaal fijn/terecht en je weet zelf ook wel waarom ...)
Les: nooit meer doen zonder back-up.
Voor wie nog iets wil zeggen over databases ... het kan weer ... maar hou het een beetje beschaafd ;-)