Donnerstag, 24. Mai 2007
Tabelle gecrashed...
Einem Kunden ist eine 8 GB große MySQL-Tabelle vergangene Nacht gecrashed.
Da die Datenbank allerdings auf einem Produktivsystem von ihm liegt und die Tabelle nicht mal eben so parallel zum normalen Betrieb recovert werden kann bzw. sollte, haben wir die defekte Tabelle kurzerhand auf ein benachbartes System übertragen, dort reparieren lassen und wieder zurückkopiert...
Im Nachhinein betrachtet war es wohl sowieso die schnellste Variante mit dem Problem umzugehen... Nichts desto trotz habe ich dem Kunden empfohlen seine Tabellen in Zukunft zu "mergen", d.h. keine einzelne 8 GB große Tabelle zu betreiben, sondern mehrere kleine in einem MERGE zusammenzufassen. Ich trau aus Erfahrung keiner MySQL-Tabelle größer als 5 GB und da MySQL 5.1 noch nicht wirklich Partitionierung kann ist das wohl die beste Lösung für den Moment...
... wobei man natürlich auch über einen wechsel des DBMS nachdenken könnte 
Hat da jemand eine Idee?
Zumindest ist mir keine gute Lösung bekannt, denn alle Rows werden durchgehend ausgelesen und benötigt...
Die 8 GB hab ich zwar noch lange nicht, aber Gedanken kann man sich ja immer machen.
Da kommst Du auch mit Merged oder Partitioned Tabelen weiter... Letzteres ist zu bevorzugen, hat aber noch keinen produktiv-status in MySQL 5.1...
Es scheint irgendwie schneller zu sein, wenn MySQL 2x4 GB statt 1x8 GB handlen muss... Warum auch immer
Ansonsten kann man Tabellen natürlich ihrer Bestimmung entsprechend anpassen... Einfach mal hier und dort ein paar Indexe setzen...
Aber ich lauf ja eh noch auf MySQL 4.1
meine groesseren dbs laufen seitdem auf postgresql.
tabellenreparaturen sind da im gegensatz zu mysql gar nicht vorgesehen, aber der einzige defekt den ich bisher hatte beschränkte sich im endeffekt auf wenige rows und beeinträchtigte die funktionalität der db in keiner weise (solange man nicht auf exakt diese rows zugreifen wollte).
tom
Suche
Read this blog!
Kategorien
Blog abonnieren
Buttons
Kommentare
