MYSQL Profis unter uns?
-
- Daten aus einer DB in die zweite DB mit anderen Tabellennamen kopieren.
INSERT INTO DB1.TABLE1 SELECT * FROM DB2.TABLE1;
- schau dir mal das hier an: https://stackoverflow.com/questions/16117306/combine-two-mysql-table-with-same-column-name
-
stehen diese tabellen für sich? oder hat diese noch eine datenrelation zu einer anderen tabelle.
wenn ja, dann musst du mit den ids aufpassen, da ja dann die relation in der anderen datenbank nicht mehr passt.wenn nein, dann kannst du die daten in dern neuen tabelle:
a) wenn die spalte für ids nicht mit dem unique kenner angelegt wurde einfach einfügen.
b) wenn die id spalte mit unique kenner, dann entwender ohne id einfügen so dass die id neu vergeben wird oder neu nummerieren.aber erst einmal mit alternative a probieren.
eine Oberfläche wie heidiSQL ist auf jeden fall hilfreich, da es dir das nachschlagen einiger befehle für die console erspart. -
Ok, dann hab ich viel zu lesen.
Ich hatte auch überlegt alles in eine Influx Datenbank umzuziehen, geht das evtl. einher mit der Migration der Datenbanken? Evtl. kann ich mir so gleich einen Überblick verschaffen.
Ich stelle hier nach der Arbeit Screenshots ein, dann kann ich es besser erklären.
Vielen Dank für die vielen Antworten
-
So sieht die ganze Geschichte aus. Bevor ich es falsch beschreibe, sagt Euch der Screenshot bestimmt mehr.
Zusammengefügt werden sollen die Datenbanken ...maticdb und ..maticdb_02. Wobei ...maticdb_02 in ...maticdb eingefügt werden soll
Wobei wohl nur die Tabellen mit ts_ hinzugefügt werden müssen. Bei allen anderen hat sich nichts geändert. Diese haben, soweit ich es sehe, keine eindeutige id, sondern dieses ts, was wohl ein Zeitstempel ist?
Was dans ganze sicherlich einfacher macht, denke ich
-
ts ist der UNIXTIMESTAMP, ein Wert in Sekunden seit 00:00:00 am 01.01.1970
kannst Du hier online checken: https://www.epochconverter.com
Solange nicht mehrere Werte innerhalb einer Sekunde in die Tabelle eingetragen werden, ist ts eindeutig.
-
@Daddeldu Danke, Unixtime, genau das war es.
Habe jetzt mal eine 3. Datenbank angelegt, die Struktur der alten kopiert und fülle sie jetzt. Scheint zu finktionieren
ALTER TABLE ...maticdb_03.ts_number DISABLE KEYS; INSERT INTO ...maticdb_03.ts_number SELECT * FROM ...maticdb.ts_number; ALTER TABLE ...maticdb_03.ts_number ENABLE KEYS;Jedenfalls gab es keinen Fehler und zu den ursprünglichen 190308147 Einträgen wurden 102398438 Einträge hinzugefügt.
Danke Euch
-
Nun kommen aber die Fehler...
sobald ich einen Zeitraum auswähle der länger zurück liegt, z.B. November 2019, bekomme ich einen #1040 - Too many connections Fehler und komme erst weider in phpMyAdmin rein, wenn ich die mysql Instanz stoppe.
-
Google findet Treffer ohne Ende zu dem Fehler...
https://stackoverflow.com/questions/730953/how-to-fix-mysql-connect-too-many-connections
oder auch
Hängt wahrscheinlich mit der Checkbox“Parallelanfragen erlauben“ im Adapter zusammen. Standard sind laut der Links oben max 151 Verbindungen gleichzeitig.
-
@Daddeldu sagte in MYSQL Profis unter uns?:
Google findet Treffer ohne Ende zu dem Fehler...
https://stackoverflow.com/questions/730953/how-to-fix-mysql-connect-too-many-connections
oder auch
Hängt wahrscheinlich mit der Checkbox“Parallelanfragen erlauben“ im Adapter zusammen. Standard sind laut der Links oben max 151 Verbindungen gleichzeitig.
Ja, da bin ich dran mich durch Google zu kämpfen. Da gibt es so viele verschiedene Möglichkeiten.
Größtes Problem gerade, ich weiß das Passwort des root user nicht
-
Ich würde auch mal nen select count auf einen bestimmten Zeitraum machen, um zu sehen, wieviele Datensätze da kommen um den dann irgendwie sinnvoll zu begrenzen. Ob das nötig ist weiß ich zwar nicht, aber bei zig 1000 Datensätzen könnte es irgendwann eng werden.
Vom MySQL-Server oder vom Raspi/Tinkerboard? Kannst Du doch notfalls beides zurücksetzen. -
@Daddeldu sagte in MYSQL Profis unter uns?:
Ich würde auch mal nen select count auf einen bestimmten Zeitraum machen, um zu sehen, wieviele Datensätze da kommen um den dann irgendwie sinnvoll zu begrenzen. Ob das nötig ist weiß ich zwar nicht, aber bei zig 1000 Datensätzen könnte es irgendwann eng werden.
Vom MySQL-Server oder vom Raspi/Tinkerboard? Kannst Du doch notfalls beides zurücksetzen.Irgendwie geht gar nichts, alles was ich im Netz finde, bewirkt entweder nichts, oder es fehlen die root Rechte, wo ich das Passwort nicht habe.
Die Tipps, wie ich das root Passwort von MYSQL zurück setze, funktionieren irgendwie auch alle nicht.
Wahrscheinlich stelle ich mich zu dumm an...
-
Erstmal mysql stoppen, siehe 2. hier unter diesem Link:
https://tableplus.com/blog/2018/10/how-to-start-stop-restart-mysql-server.html
danach ohne Anmeldedaten starten und Passwort zurücksetzen:
https://www.patrick-gotthard.de/mysql-root-passwort-zuruecksetzen
und zum Schluß wieder starten und mit neuem root-pow anmelden
-
Ich habe mir mal gerade die Unix Timestamps angesehen, ich denke hier liegt das Problem
1539144518784: Realzeit: 20.07.50743 - 17:06:24
Kann der Fehler daher kommen? Ich habe jetzt mal 20 Werte wild aus der alten DB probiert, von der ersten bis zur letzten Seite, die sind alle Murks
-
Dieser Zeitstempel ist vom 10. Oktober 2018 und beinhaltet Millisekunden.
1539144518784 Wobei die 784 die Millisekunden sind. Laß die 3 Stellen weg und teste nur die 1539144518 dann siehst Du es.
Die alte DB beinhaltet wahrscheinlich Millisekunden im Zeitstempel, die aktuelle nicht. Ob dem so ist und die Werte plausibel sind, kannst nur Du checken. Beide Datenbanken einfach nur mergen dürfte damit sinnlos sein. Für jedes Datum müsste der Zeitstempel beim Kopieren entsprechend manipuliert werden, so daß beide dieselbe Zeitbasis haben.
Wenn Du beim SQL-Statement die einzelnen Spalten anstelle von * angibst, kannst Du bei den VALUES dann z.B. ts/1000 als Zeitstempel einfügen.
Das Prinzip ist im Link unten beschrieben, alternativ in der alten DB erstmal den Zeitstempel mit ts/1000 updaten und dann 1:1 mergen.https://www.w3resource.com/sql/update-statement/update-columns-using-arithmetical-expression.php
-
@Daddeldu sagte in MYSQL Profis unter uns?:
Dieser Zeitstempel ist vom 10. Oktober 2018 und beinhaltet Millisekunden.
1539144518784 Wobei die 784 die Millisekunden sind. Laß die 3 Stellen weg und teste nur die 1539144518 dann siehst Du es.
Die alte DB beinhaltet wahrscheinlich Millisekunden im Zeitstempel, die aktuelle nicht. Ob dem so ist und die Werte plausibel sind, kannst nur Du checken. Beide Datenbanken einfach nur mergen dürfte damit sinnlos sein. Für jedes Datum müsste der Zeitstempel beim Kopieren entsprechend manipuliert werden, so daß beide dieselbe Zeitbasis haben.
Wenn Du beim SQL-Statement die einzelnen Spalten anstelle von * angibst, kannst Du bei den VALUES dann z.B. ts/1000 als Zeitstempel einfügen.
Das Prinzip ist im Link unten beschrieben, alternativ in der alten DB erstmal den Zeitstempel mit ts/1000 updaten und dann 1:1 mergen.https://www.w3resource.com/sql/update-statement/update-columns-using-arithmetical-expression.php
Vielen Dank. Das werde ich morgen mal in Ruhe probieren.
Ich sag dann bescheid.
-
Ich hab gefunden was die Probleme verursacht, was mich veranlasst das Projekt "Datenbank zusammenführung" sein zu lassen.
Die Datenpunkte sind in der neuen und der alten Tabelle vollkommen unterschiedlich. Das bekomme ich nicht auseinander. Die selben Datenpunkte haben verschiedene id´s, und in der neuen Tabelle sind es sogar mehr.
Daher danke für Eure Hilfe, aber ich habe jetzt die Diagramme mit den alten Daten erstellt die ich brauchte, nun lasse ich die alten Daten verloren, und gut ist
-
ist für dich dann damit das Thema erledigt?
Ich suche und brauche nämlich auch noch dringend einen SQL-Profi bzw. zumindest einen, der mir mit der sql-Instanz weiterhelfen kann - will nur nicht deinen Thread damit "zerschießen".Mein Problem findet sich hier. Problem ist, dass mein Log-File immer größer wird und ich täglich mind. um die 1MB Größe liege. Vor ein paar Tagen hatte ich allerdings auch schon 36MB.
Ich habe eine MariaDB auf einer Synology. Ich weiß nicht mehr weiter und wäre schön, wenn sich mal einer erbarmt, mir zu helfen...
Danke
Marcus
