database locatie en verplaatsen?
Aangezien een database ook gewoon een bestand is, vroeg ik me af waar deze bestanden eigenlijk worden opgeslagen op de server.
Ook vraag ik me af of het mogelijk is om een database op te slaan in een andere locatie dan de standaardlocatie. Kun je bijvoorbeeld een database die bij een specifiek project hoort in de map van dat project opslaan? Bijvoorbeeld zoiets:
Code (php)
1
2
3
4
2
3
4
/pad/naar/project/tuinkabouters
/database/database.sql
/prive
/www
/database/database.sql
/prive
/www
Standaard worden de datafiles opgeslagen in /var/lib/mysql. Geen idee welke malloot dat heeft bedacht overigens; zou mijn keuze niet zijn. Maar in de config kun je de datafiles eenvoudig verplaatsen:
datadir = /mysql/data
De mappen onder die datadir komen overeen met de databases die je hebt aangemaakt. In elke database-map komen per tabel bestanden voor de tabeldefinitie, de data, en de indices. Althans, voor MyISAM.
Bij InnoDB werkt het allemaal net even anders: als je de standaardinstelling gebruikt, komt alles in 1 groot bestand. Je kan echter aangeven in my.cnf dat je InnoDB wilt opsplitsen per tabel:
innodb_file_per_table
Op een Unix-systeem kun je ook nog gebruik maken van symbolic links. Als je niet alle databases onder je datadir wilt hebben, kun je die op een willekeurige plek neerzetten en vanuit de datadir een symbolic link leggen naar de echte locatie:
ln -s /project/tuinkabouter/paddestoel /mysql/data/paddestoel
In de praktijk gebruik ik dit bijvoorbeeld om sommige databases op een andere diskset te zetten, zodat het aantal I/O's beter wordt verdeeld. Let wel op dat de mysql-user het ownership heeft van de database-directory en alle bestanden die erin staan.
Gewijzigd op 02/12/2014 20:08:34 door Willem vp
Het wordt vaak opgeslagen in een /data directory. Waar deze standaard na een installatie zit, weet ik niet, maar in my.cnf / my.ini is deze wel te vinden onder 'datadir'.
Het punt is dat de data daarin volgens mij binair opgeslagen wordt, en dat het niet zomaar uitwisselbaar is. Het zijn frm, myd en myi extenties. Let wel dat deze databases niet zomaar uitwisselbaar zijn met andere versies van MySQL.
De enige beste manier om ze uit te wisselen is via de 'mysqldump'-binairy, of als je veel geduld hebt... kan je hem exporteren/dumpen met PhpMyAdmin (werkt behoorlijk ^%$^$).
Als we het niet over MySQL hebben, dan heb je ook SQLlite. Deze is wel uitwisselbaar als file.
MyISAM-tabellen kunnen daar wel tegen. Let wel op dat als je de tabellen wilt verplaatsen, je ze eerst lockt (of MySQL stopt). Na het verplaatsen moet je vaak wel nog het ownership goed zetten.
InnoDB-files kun je *niet* verplaatsen naar een andere server. Ook na een herinstallatie van je systeem (na een crash van je /usr-partitie, bijvoorbeeld) kun je de tabellen weggooien, of je moet heel erg veel tijd willen steken in reparatie. (Nog een reden om dat $#%^ InnoDB over de schutting te gooien...)
Wat ik zelf de meest praktische manier vind om met mysqldump te werken is iets in de trant van:
mysqldump database | mysql -h andereserver nieuwedatabase
Op die manier hoef je niet je hele database in een tmp-bestand te dumpen.
Gewijzigd op 02/12/2014 18:56:02 door Willem vp
Maar stel dus dat je een database in de map van een project kunt opslaan, dan heb je het complete project in één map staan. Dan kun je per project-map besluiten of je dat project wel of niet wilt back-uppen. Dat lijkt me wel handig. Maar als ik jullie opmerkingen zo eens lees dan is het nog niet zo eenvoudig dus.
Ik moet me er nog in verdiepen, maar wellicht heeft Plesk zelf nog een of andere handige optie waarmee je back-ups kunt maken.
Willem vp op 02/12/2014 18:55:22:
Dit meen je toch niet echt? Technisch gezien is InnoDB een enorme verbetering en MySQL groeit daarmee richting meer zwaardere DBMS engines zoals Oracle. InnoDB ondersteunt transacties, rollback, commit, betere support van Foreign Keys, Row level locking, full Auto recovery from crash enz. InnoDB over de schutting gooien is te vergelijken alsof je met msdos 6.0 wilt blijven werken.Nog een reden om dat $#%^ InnoDB over de schutting te gooien...
Toevoeging op 02/12/2014 21:01:31:
@Ozzie je kan met het statement: mysql> show variables like '%dir%'; uitvinden waar de/het bestand(en) nu staat of staan. mysql> show variables geef alle variabelen van het Mysql Engine.
==>> Jouw vraag hoe je het beste backups kan maken:
Voor backup van de hele database heb ik bijvoorbeeld in de cron staan:
Code (php)
1
mysqldump -uroot -p******* --all-databases >/media/backup/alldb.sql 2>/media/backup/backup_allDB.log
Gewijzigd op 02/12/2014 21:21:49 door Aad B
Aad B op 02/12/2014 20:53:39:
Willem vp op 02/12/2014 18:55:22:
Dit meen je toch niet echt? Technisch gezien is InnoDB een enorme verbetering en MySQL groeit daarmee richting meer zwaardere DBMS engines zoals Oracle. InnoDB ondsersteunt transacties, rollback, commit, betere support van Foreign Keys, Row level locking, full Auto recovery from crash enz. InnoDB over de schutting gooien is te vergelijken alsof je met msdos 6.0 wilt blijven werken.Nog een reden om dat $#%^ InnoDB over de schutting te gooien...
Nou, het hangt een beetje van de toepassing af. Als je veel inserts of updates hebt is InnoDB wel handiger vanwege die row level locking, maar verder is InnoDB vooral takketraag. Als ik een miljoen records wil deleten uit een tabel met een stuk of 25 miljoen records dan lukt me dat met een MyISAM- of Aria-tabel in een minuut of vijf. In een InnoDB-tabel kost dat meer dan een uur. En dan gebruiken we de InnoDB-engine van MariaDB, die al een stuk beter performt dan die van MySQL. Het nadeel van MyISAM is dat ik het deleten in chunks van 5000 records moet doen, omdat de tabel anders te lang gelockt blijft voor de inserts die ondertussen moeten worden gedaan.
Een ander nadeel van InnoDB is dat je code moet om kunnen gaan met deadlocks die je te pas en te onpas krijgt, zelfs als je geen transacties gebruikt. MyISAM heeft daar geen last van.
Als je InnoDB gebruikt, kun je het ook wel vergeten om even snel MySQL te herstarten. Het flushen van de buffer pool duurt namelijk best lang; doorgaans hou ik rekening met een minuut per GB aan buffer pool, maar als je pech hebt duurt het 5x zo lang. En heb niet het lef om het mysqld-proces voortijdig te beëindigen, want dan moeten de tabellen bij de eerstvolgende startup gerecoverd worden en dat duurt doorgaans langer.
Overigens kun je die shutdown wel versnellen door het flushen wat te tweaken. Tweaken is iets wat bij InnoDB sowieso moet. Met de standaard instellingen heb je een performance van nul komma heel weinig. Door wat te spelen met my.cnf kun je InnoDB soms wel 50x zo snel krijgen. MyISAM daarentegen doet het out of the box al best goed.
Wat in mijn situatie in ieder geval een killer is, is het feit dat je InnoDB-bestanden niet naar een andere server kunt kopiëren. En om tabellen met 200-300 miljoen records naar een andere server te verhuizen via mysqldump is voor niemand leuk...
Ik kan dus eigenlijk alleen maar concluderen dat InnoDB op papier best wel leuk is, maar dat het in de praktijk zwaar zuigt. De enige situatie waarin ik het zou toepassen is als ik echt niet zonder transacties zou kunnen. En als we nog een half jaartje geduld hebben, dan ondersteunt Aria ook transacties en hebben we InnoDB dus helemaal nergens meer voor nodig. ;-)
Willem vp op 02/12/2014 21:44:18:
Wellicht nog wat terkortkomingen in uitvoering. Ikzelf werk met twee piepkleine MySQL implementaties en een hondertal Oracle 11G rdbms die alles hebben wat jij in InnoDB verguist. InnoDB gaat richting Oracle technologie maar wellicht laat de performance nog te wensen over. Oracle heeft ook geen losse tabellen zoals isam. Dan nog het punt van deadlocks: deadlocks zijn design errors: A deadlock is not an RDBMS error. It is a deadlock due to user error in the design of an application or from issuing incorrect ad-hoc SQL. Andere deadlocks bestaan niet.Ik kan dus eigenlijk alleen maar concluderen dat InnoDB op papier best wel leuk is, maar dat het in de praktijk zwaar zuigt. De enige situatie waarin ik het zou toepassen is als ik echt niet zonder transacties zou kunnen. En als we nog een half jaartje geduld hebben, dan ondersteunt Aria ook transacties en hebben we InnoDB dus helemaal nergens meer voor nodig. ;-)
Zodra Aria ook transacties ondersteund garandeer ik je dezelfde performace issues. Het komt gewoon door het transactiemechanisme. Met >25M records kan je beter kiezen voor Oracle
;-)
Gewijzigd op 02/12/2014 22:18:45 door Aad B