Ich mache eine Datensicherung mit BACKUP TABLE. Das funktioniert aber
nur auf dem Server-Rechner. Bei den Clients wird der Befehl nicht
ausgeführt. Ist das so oder mache ich etwas falsch? z.B.
BACKUP TABLE kunden TO "C:/TEST";
Am Wed, 16 Aug 2006 12:55:20 -0700 schrieb dustymueller:
> Ich mache eine Datensicherung mit BACKUP TABLE. Das funktioniert aber
> nur auf dem Server-Rechner. Bei den Clients wird der Befehl nicht
> ausgeführt. Ist das so oder mache ich etwas falsch? z.B.
>
> BACKUP TABLE kunden TO "C:/TEST";
Gleiche mysql version?
Martin
Martin Kaffanke schrieb:
> Gleiche mysql version?
Der Client greift doch auf den MySQL-Server des Servers zu. Also -
gleiche MySQL-Version. Version: 4.1
Ich will ja vom Client aus ein Backup des Server-Datenbestandes machen.
dustymueller@web.de wrote:
> Ich mache eine Datensicherung mit BACKUP TABLE. Das funktioniert aber
> nur auf dem Server-Rechner. Bei den Clients wird der Befehl nicht
> ausgeführt. Ist das so oder mache ich etwas falsch? z.B.
>
> BACKUP TABLE kunden TO "C:/TEST";
1. LOL
2. LOOOL
3. Wenn du von einem Client - irgendeinem Client - ein SQL-Statement
absetzt, was meinst du wohl wo das ausgeführt wird? (evpugvt, qnf jveq
nhs qrz Freire nhftrsüueg)
4. Schau doch bei Gelegenheit mal ins Handbuch. Da steht u.a. auch
drin welchen Einschränkungen Statements unterliegen, die Files im
Filesystem erzeugen. Außer BACKUP TABLE ist das auch SELECT ... INTO
OUTFILE. Schau auch ruhig mal bei LOAD DATA INFILE und was da der
LOCAL Modifier für eine Bedeutung hat.
5. BACKUP TABLE ist deprecated. Tatsächlich verstehen das aktuelle
MySQLs schon gar nicht mehr. Du willst wahrscheinlich viel eher
mysqldump benutzen. Und natürlich möchtest du das Kapitel "Desaster
Recovery" aka "Backup und Restore" im Handbuch lesen.
XL
Axel Schwenke schrieb:
> 1. LOL
> 2. LOOOL
Also, lautes Lachen bringt mich nicht weiter und sonst auch keinen.
Wenn es Dir jedoch Befriedigung verschafft, dann kannst Du natürlich
gerne weitere LOL-Beiträge spammen.
> 3. Wenn du von einem Client - irgendeinem Client - ein SQL-Statement
> absetzt, was meinst du wohl wo das ausgeführt wird? (evpugvt, qnf jveq
> nhs qrz Freire nhftrsüueg)
Was soll die Frage???
> 4. Schau doch bei Gelegenheit mal ins Handbuch. Da steht u.a. auch
> drin welchen Einschränkungen Statements unterliegen, die Files im
> Filesystem erzeugen. Außer BACKUP TABLE ist das auch SELECT ... INTO
> OUTFILE. Schau auch ruhig mal bei LOAD DATA INFILE und was da der
> LOCAL Modifier für eine Bedeutung hat.
Im (Online-) Handbuch habe ich selbstverständlich schon
nachgeschlagen.
> 5. BACKUP TABLE ist deprecated. Tatsächlich verstehen das aktuelle
> MySQLs schon gar nicht mehr. Du willst wahrscheinlich viel eher
> mysqldump benutzen. Und natürlich möchtest du das Kapitel "Desaster
> Recovery" aka "Backup und Restore" im Handbuch lesen.
Nein, ich möchte nicht mysqldump benutzen. Ich möchte von einem
Client die Kopie einer Datenbank respektive deren Tabellen als Backup.
Eigentlich ganz einfach.
Wenn der MySQL-Server natürlich nicht auf ein Laufwerk eines Clients
zugreifen kann, dann ist das unter Umständen nachvollziehbar und ich
muss mir eine andere Sicherungsvariante überlegen.
dustymueller@web.de schrieb:
Im Deutschen Usenet sind komplette Namen erwünscht.
> Axel Schwenke schrieb:
> 3. Wenn du von einem Client - irgendeinem Client - ein SQL-Statement
>> absetzt, was meinst du wohl wo das ausgeführt wird? (evpugvt, qnf jveq
>> nhs qrz Freire nhftrsüueg)
>
> Was soll die Frage???
>
Sie soll Deine Aufmerksamkeit auf ein Problem lenken. Ist das so
schwer zu verstehen?
>> 4. Schau doch bei Gelegenheit mal ins Handbuch. Da steht u.a. auch
>> drin welchen Einschränkungen Statements unterliegen, die Files im
>> Filesystem erzeugen. Außer BACKUP TABLE ist das auch SELECT ... INTO
>> OUTFILE. Schau auch ruhig mal bei LOAD DATA INFILE und was da der
>> LOCAL Modifier für eine Bedeutung hat.
>
> Im (Online-) Handbuch habe ich selbstverständlich schon
> nachgeschlagen.
>
Selbstverständlich ist etwas anderes, nach meiner Erfahrung in dieser
Gruppe. Deshalb ist der Hinweis immer sinnvoll.
>
>> 5. BACKUP TABLE ist deprecated. Tatsächlich verstehen das aktuelle
>> MySQLs schon gar nicht mehr. Du willst wahrscheinlich viel eher
>> mysqldump benutzen. Und natürlich möchtest du das Kapitel "Desaster
>> Recovery" aka "Backup und Restore" im Handbuch lesen.
>
> Nein, ich möchte nicht mysqldump benutzen.
Warum nicht?
> Ich möchte von einem
> Client die Kopie einer Datenbank respektive deren Tabellen als Backup.
> Eigentlich ganz einfach.
Und was davon tut mysqldump Deiner Meinung nach nicht?
>
> Wenn der MySQL-Server natürlich nicht auf ein Laufwerk eines Clients
> zugreifen kann, dann ist das unter Umständen nachvollziehbar und ich
> muss mir eine andere Sicherungsvariante überlegen.
Du meinst, Du könntest Dir auch Umstände vorstellen, in dem ein
Datenbankserver auf Daten zugreifen kann, die auf dem Laufwerk eines
Clients liegen? Ohne dass dieses Laufwerk in irgendeiner Form im Netz
zur Verfügung steht (vulgo "Freigabe")? Welche Umstände wären das
denn? Und wie würdest Du Dir eine technische Realisierung vorstellen?
Ich frage, weil ich ungern neue Entwicklungen verpasse, und
möglicherweise bist Du da was ganz Großem auf der Spur.
Hallo Christian,
> Du meinst, Du könntest Dir auch Umstände vorstellen, in dem ein
> Datenbankserver auf Daten zugreifen kann, die auf dem Laufwerk eines
> Clients liegen?
Es wären genau die gleichen Umstände, mit denen mysqlimport Daten von einer
lokal auf dem Client liegenden Datei in den Server bekommt und mysqldump
das gleiche in Gegenrichtung.
Nur eben mit mit Initiierung durch ein Meta-Kommando eines interaktiven
Client.
> Ich frage, weil ich ungern neue Entwicklungen verpasse, und
> möglicherweise bist Du da was ganz Großem auf der Spur.
Wo soll da die neue Entwicklung sein?
Siegfried
--
http://www.schmidt.ath.cx
dustymueller@web.de wrote:
> Axel Schwenke schrieb:
>
>> 1. LOL
>> 2. LOOOL
>
> Also, lautes Lachen bringt mich nicht weiter und sonst auch keinen.
> Wenn es Dir jedoch Befriedigung verschafft, dann kannst Du natürlich
> gerne weitere LOL-Beiträge spammen.
Aha. Humor hast du also auch keinen.
>> 3. Wenn du von einem Client - irgendeinem Client - ein SQL-Statement
>> absetzt, was meinst du wohl wo das ausgeführt wird? (evpugvt, qnf jveq
>> nhs qrz Freire nhftrsüueg)
>
> Was soll die Frage???
Dir einen Hinweis geben, in welcher Richtung dein Horizont noch
Erweiterungsmöglichkeiten hat.
>> 4. Schau doch bei Gelegenheit mal ins Handbuch. Da steht u.a. auch
>> drin welchen Einschränkungen Statements unterliegen, die Files im
>> Filesystem erzeugen. Außer BACKUP TABLE ist das auch SELECT ... INTO
>> OUTFILE. Schau auch ruhig mal bei LOAD DATA INFILE und was da der
>> LOCAL Modifier für eine Bedeutung hat.
>
> Im (Online-) Handbuch habe ich selbstverständlich schon
> nachgeschlagen.
Das halte ich für eine Lüg^H^H^HSchutzbehauptung.
http://dev.mysql.com/doc/refman/5.0/en/select.html
bis zu "The SELECT ... INTO OUTFILE 'file_name' form of SELECT..."
scrollen und *lesen*
>> 5. BACKUP TABLE ist deprecated. Tatsächlich verstehen das aktuelle
>> MySQLs schon gar nicht mehr. Du willst wahrscheinlich viel eher
>> mysqldump benutzen. Und natürlich möchtest du das Kapitel "Desaster
>> Recovery" aka "Backup und Restore" im Handbuch lesen.
>
> Nein, ich möchte nicht mysqldump benutzen. Ich möchte von einem
> Client die Kopie einer Datenbank respektive deren Tabellen als Backup.
> Eigentlich ganz einfach.
Möchtest du auch noch erläutern, weswegen du auf einer veralteten und
funktional eingeschränkten Methode für dein Backup bestehst? Das Mittel
der Wahl ist ganz klar mysqldump.
XL
Siegfried Schmidt schrieb:
> Hallo Christian,
>
>> Du meinst, Du könntest Dir auch Umstände vorstellen, in dem ein
>> Datenbankserver auf Daten zugreifen kann, die auf dem Laufwerk eines
>> Clients liegen?
>
> Es wären genau die gleichen Umstände, mit denen mysqlimport Daten von einer
> lokal auf dem Client liegenden Datei in den Server bekommt und mysqldump
> das gleiche in Gegenrichtung.
>
Vielleicht doch mal das Handbuch ...?
Sichern:
siegfried@client> mysqldump -h server -u user -p db > db.sql
Zurückspielen:
siegfried@client> mysql -h server -u user -p db < db.sql
Ja, Du brauchst dazu exakt zwei MySQL-Programme auf Deinem Client. Ja,
nach dem ersten Schritt liegt ein Backup Deiner Datenbank auf dem
Client. Nein, der MySQL-Server hatte keinen Zugriff auf Dein "Laufwerk
C:". In beiden Fällen nicht.
Man kennt dieses Verfahren auch unter dem Namen
"Client-Server-Kommunikation". Ist allerdings im Windows-Umwelt noch
relativ neu.
> Nur eben mit mit Initiierung durch ein Meta-Kommando eines interaktiven
> Client.
>
Sowas nennt man "Sicherheitsloch".
>> Ich frage, weil ich ungern neue Entwicklungen verpasse, und
>> möglicherweise bist Du da was ganz Großem auf der Spur.
>
> Wo soll da die neue Entwicklung sein?
Ok, ich füge das nächste Mal große rote leuchtende
On Thu, 17 Aug 2006 17:23:57 +0200, Axel Schwenke wrote:
> Möchtest du auch noch erläutern, weswegen du auf einer veralteten und
> funktional eingeschränkten Methode für dein Backup bestehst? Das Mittel
> der Wahl ist ganz klar mysqldump.
Er ist jetzt quengelig und mag nicht mehr zuhören.
Gruß,
Matthias
Christian Kirsch wrote:
> dustymueller@web.de schrieb:
[...]
>> Wenn der MySQL-Server natürlich nicht auf ein Laufwerk eines Clients
>> zugreifen kann, dann ist das unter Umständen nachvollziehbar und ich
>> muss mir eine andere Sicherungsvariante überlegen.
>
> Du meinst, Du könntest Dir auch Umstände vorstellen, in dem ein
> Datenbankserver auf Daten zugreifen kann, die auf dem Laufwerk eines
> Clients liegen?
man LOAD DATA LOCAL INFILE
> Und wie würdest Du Dir eine technische Realisierung vorstellen?
MySQL-Server erhält Query - MySQL-Server teilt verbundenem Client mit, daÃ
er eine Datei von ihm braucht - MySQL-Client versucht die Datei einzulesen
und schickt ihren Inhalt zum Server - Server importiert sie.
> Ich frage, weil ich ungern neue Entwicklungen verpasse, und
> möglicherweise bist Du da was ganz GroÃem auf der Spur.
Nein, das Client-Server-Prinzip ist schon etwas älter.
Thomas
--
Ich flame nämlich nie. (Michael Enezian in
<3BE11D86.28D92E1B@webshuttle.ch>)