Mysql Structure Incremental Backup

[Graggor]

Sinds kort ben ik bezig om een schoolproject-CMS te verbeteren en hier functies aan toe te voegen om deze te gebruiken als community website.

Omdat deze software op meerdere systemen draait is het nodig voor mij om ook van de SQL een backup te maken, echter moet dit alleen van de structuur, niet van de data zelf.
Dit lukt prima met phpmyadmin, ik kan de gehele structuur back-uppen.

Aangezien de websites in ontwikkeling zijn maar toch zelf draaien met ieders hun eigen data, is het nodig om van alleen de structuur een update te maken. Dit kan ik echter nergens terugvinden.

Het enige dat ik gevonden heb is dat er van de gehele database een incrementele backup gemaakt kan worden via een sqldump, echter niet van de structuur.

Is zoiets mogelijk, en zo ja hoe?

[Kettrick]

De zoektermen waarmee je dit waarschijnlijk goed op kan lossen zijn 'mysql schema migration', in java land heb ik dit destijds met liquibase opgelost, maar er zijn ongetwijfeld meerdere oplossingen voor dat probleem.

[Graggor]

Kettrick schreef op dinsdag 03 februari 2015 @ 23:53:
De zoektermen waarmee je dit waarschijnlijk goed op kan lossen zijn 'mysql schema migration', in java land heb ik dit destijds met liquibase opgelost, maar er zijn ongetwijfeld meerdere oplossingen voor dat probleem.

Bedankt! Dit zocht ik. Blijkbaar ben ik nog niet echt helemaal goed met de termen.

Als iemand anders dit topic vind:
Heb meerdere dingen gevonden voor o.a. linux: http://schemasync.org/
en een meer algemene informatiebron:
http://blog.webyog.com/20...ync-your-database-schema/

Edit: Helaas kan ik nog niks vinden over migraties zonder dat er vergeleken hoeft te worden, maar met bovenstaande informatie kan ik voor nu al uit de voeten!

[ Voor 11% gewijzigd door Graggor op 03-02-2015 23:59 ]

[ACM]

3dd1e schreef op dinsdag 03 februari 2015 @ 23:57:
Edit: Helaas kan ik nog niks vinden over migraties zonder dat er vergeleken hoeft te worden, maar met bovenstaande informatie kan ik voor nu al uit de voeten!

Je zal altijd een 'van'- en 'naar'-situatie moeten hebben voor dit soort dingen, dat moet bij alle vormen van incrementeel werken (zoals svn/git), tenzij je een andere manier hebt om dat bij te houden (zoals transactie-ids bij records in een database, maar dan moet je wel de vorige 'tijd' onthouden).

Je kan ook nog zoeken op 'database version control' enzo, maar waarschijnlijk krijg je dan ongeveer dezelfde resulaten als je al had.

Wellicht kan je bij sommige tool de 'van'-situatie vervangen door een volledige schema-backup van de oude situatie (dus een sql-file). In dat geval zou je elke keer dat je een incrementele backup wilt maken moeten vergelijken met de volledige backup en daarna de 'patch' steeds opnieuw kunnen genereren. En daarna eventueel ook de volledige backup vervangen door een nieuwe voor de volgende keer dat je een patch wilt maken.

Een andere optie is een template-database maken, waarbij je gewoon allemaal lege tabellen aanmaakt en daar die online-migratie tools van af laat leiden. En af en toe werk je die bij tot de actuele situatie, zodat je weer verse patches kunt maken.

Maar het is wel een vrij gevaarlijke manier van online-migraties forceren. Wellicht moet je soms een nieuw veld gelijk ook vullen met data (bijv afgeleid van bestaande data) of een kolom voor je 'm dropt eerst kopieren naar een andere tabel.
Met bewust geschreven migratiescripts hou je daar - hopelijk - wat meer rekening mee

[Gomez12]

Wat is de impact als het schema niet klopt? Want het schema zegt eigenlijk vrij weinig, een kolom hernoemen is qua schema een verwijdering van 1 kolom en een toevoeging van een andere kolom.

Ik meen dat sommige migratietools daar rekening mee proberen te houden door ook deels de data erbij te betrekken en op basis van de data een rename actie doen, maar het blijft trucen met een redelijke foutkans.

In principe zou ik ook zeggen : Handmatige scripts for the win.
En mocht het fout zijn toch een grote impact hebben (omdat er bijv een automatisch process op loopt) dan lege database creeeren, daar het script op draaien en structuur vergelijken met de brondb, komt het overeen dan kan het data-technisch nog fout zijn, maar structuurtechnisch breekt het niets.

Andere mogelijkheid die ik ook wel eens gezien heb is : Devvers gewoon geen inlog geven met rechten op structuurwijzigingen en dan een los tooltje maken met "hidden username / password" waarin men sql statements kan invoeren voor structuurwijzigingen. Als die tool dan logt dan heb je in ieder geval alle structuurwijzigingen raadpleegbaar vanuit je log.
Je kunt dan in ieder geval bij een nieuwe versie aan iedereen vragen : Heb je je script vergeleken met het log om te zien of je niets vergeten bent (want falend menselijk geheugen is een heel grote reden voor onvolledige handmatige scripts)