nicht angemeldet
Hallo Cheatah!
Hätte gar nicht gedacht das Du darauf antwortest ;-)
Ich will eine Datenbank mit gleichem Datenbestand an 3 Standorten haben, wobei an jedem Standort Daten ergänzt/verändert werden können.
schwierig. Ideal wäre eine Aktualisierung aller Datenbestände in (annähernd) Echtzeit.
^^^^^^^^^^^
Das ist das Problem, man kann sich auf den Kopf stellen, aber man wird nicht verhindern können, das sich auf einem der Systeme etwas verändert hat während man z.B. einen neuen Datensatz angelegt hat, und wenn 1/10 Sekunde zuvor an einem anderen Standort ebenfalls ein Datensatz angelegt wurde, haben - bei exakt gleichen Datenbeständen - diese beiden Datensätze dieselbe ID aber andere Daten - wenn zwischendurch nicht abgeglichen wurde. Ich finde es ist sicherer auf MasterID und ClinetID zurückzugreifen, da wird nur von einer Master-DB die MasterIDs verteilt, so ist sichergestellt das es zu keiner Inkonsistenz der Daten kommt!
Da ich MySQL verwende und leider an einem Standort nicht genügend Rechte habe,
Du hast eine große Macht, die Du vergisst: Du kannst den Provider wechseln. Wenn er Dir nicht genügend Rechte gibt, verlasse ihn einfach! Alles andere wäre Unsinn - Du legst Dir selbst Steine in den Weg, weil jemand anders auf stur stellt. Frage Deinen Provider, unter welchen (auch monitären) Bedingungen er Dir die von Dir benötigten Berechtigungen gibt.
Das habe ich vor kurzem schon gemacht, bis auf die ein oder andere Beschränkung mit Cronjobs bin ich da eigentlich hochzufrieden. Wenn ich alle Möglichkeiten haben will brauche ich einen eigenen Server, den ich dann selbst warten... müßte! Und das hat auch seinen Sinn das der MySQL-Port geschlossen ist - Sicherheit! Aber das Logging könnte ich da ja auch nicht machen, da nicht 1 Server pro Kunde! Aber selbst wenn ich das alles hätte, der MySQL Mechanismus ist ein Replikationsmechanismus, das heißt aber das nur auf dem MasterServer einträge gemacht/geändert werden können, die andern Datebanken sind ledigliche "Kopien" die man nur auslesen kann.
wäre dann aber trotzdem ein Beispiel _für_ Skalierbarkeit, oder?<<<
Dabei ist es sicher nicht ganz unerheblich, dass MySQL keine Foreign Keys beherrscht. Möglicherweise ist dieses DBMS auch eine ungünstige Wahl der Technik.
Das kann schon sein, aber was würden mir Foreign Keys hier bringen?
Nö. Durchdenke es genau - und überdenke auch jedwede bisher getroffene Entscheidung. Was Dich behindert, war offenbar ein Fehler, dessen Korrektur Du in Erwägung ziehen solltest.
Meinst Du den Provider? Wie gesagt, durch eine Wechsel würd eich im Prinzip nichts gewinnen, außerdem ist mir kein Provider bekannt der ein Hostingpaket mit so weitreichenden Rechten(z.B. Neustarten des MySQL-Servers) vertreibt!
Hm, ist "Client" wirklich der richtige Begriff? Wenn ich Dich richtig verstehe, wäre "Mirror" passender.
Eben nicht! Der Mirror ist im Prinzip eine Replikation eines Masters, oder? Was ich mache ist z.B. folgendes:
Ein Shop mit 3 örtlich voneinander getrennten Standorten:
1. Homepage/online-Shop beim Provider(autom. Speicherung v. Bestellungen in DB)
2. Verkaufsfläche (manuelle Aufnahme/Änderung von Bestellungen und Speicherung in DB)
3. Verwaltung (manuelle Aufnahme/Änderung von Bestellungen und Speicherung in DB)
Jeder Standort verfügt über eine eigene MySQL Datenbank(im jeweils eigenen LAN). Die Datenbestände sollen überall gleich sein. Da die DB beim Provider immer verfügbar ist würde ich diese als Master-DB verwenden, über die sich die beiden anderen Standorte(Client-DBs) abgleichen.
Wenn jetzt z.B. in der Verkaufsfläche eine Bestellung manuell eingegeben wird, und gleichzeitig im Online-Shop eine Bestellung eingeht, kommen sich die IDs beim nächsten Abgleich in die Quere. Daher hatte ich mir gedacht den Datensätzen in den Clients eigene IDs zu geben, und die MasterID erst beim Abgleich von der Master-DB vergeben zu lassen.
Dann muß ich alle Tabellen mit MySQL-Timestamps versehen und in einer extra Tabelle den letzten Synchronisations-Zeitpunkt speichern, um die Datensätze die nach der letzten Synchronisation geändert worden sind zu ermitteln.
In einem Script muß ich dann alle Datensätze die neuer als der letzte Synczeitpunkt sind per Select abfragen, die vielleicht direkt als inserts/updates/deletes speichern, dann mit Hilfe von PSCP zum Server übertragen und mit Hilfe von Plink dort ein Script starten, welches ebenso alle neuen Daten ausliest und dann die zuvor übertragenen querys ausführt. Am Ende muß ich ebenfalls die inserts/updates/deletes für den Client erzeugen und als Datei speichern, und mit PSCP die Datei runterladen und schließlich beim Client die inserts/updates/deletes ausführen.
Bleibt nur noch die Frage wie diese Synchronisation in Gang gesetzt wird, evtl. durch einen Cronjob oder beim Starten/Herunterfahren des Programms, am besten wäre natürlich bei jeder Änderung, aber das weiß ich noch nicht... mal schaun.
So sieht meine Idee zur Zeit aus, wobei ich so weit noch nicht bin, zur Zeit läuft das alles noch einfach vom Master-Server aus, der einfach eine Verbindung zu beiden DBs herstellt und alle Querys unverschlüsselt quer durchs Netz schickt... nicht wirklich gut.
Dann sind alle drei Master. Du musst Dir einen Plan jeden denkbaren Unterschieds zwischen zwei Datenbeständen machen (auf A hinzugefügt, auf B nicht vorhanden; auf A gelöscht, auf B verändert; ...), und wie Du jeweils drauf reagieren möchtest. Eventuell möchtest Du auch einzelne Datensätze (Datensatzgruppen) an einen Master binden und ihn nur dort verändern lassen.
Wie soll ich Datensatzgruppen definieren? Und dann anders behandlen, kann ich mir irgendwie nicht vorstellen?!
Der Begriff Master der kommt bei mir auch nur daher, dass sich die anderen DBs über diese abgleichen und da diese auch die MasterIDs vergibt.
Willkommen in der wunderbaren Welt der Computer ;-)
Jajaja, das wird irgendwie immer "schlimmer"!
Und Danke nochmal für Deine sehr hilfreichen Antworten!
Viele Grüße
Andreas