[php/mysql] sql dump van server A naar server B

[Explore]

Na al dat gemier met servers en configuraties, weer eens wat anders: ik wil van server A (lokale server op 't LAN) een database dump maken en deze dump copieren naar server B (dedicated server op 't net) en de dump op server B in de database zetten, natuurlijk.

Ideaal gezien wil ik dit 't liefst in 1 php script regelen, wat op server A staat, maar ik vraag me af hoe 't zit met de toegang tot MySQL op server B vanuit server A. En verder: wat is de beste methode om de dump van A naar B te krijgen? Bij voorkeur moet dit secure, dus dan zit ik te denken aan ssh of scp. Maar hoe stuur je dat aan vanuit php?

Ik heb volledig root access tot beide servers, dus ik kan tweaken wat ik wil.

Dit is geen code-request, maar meer een soort brain-storm sessie... Even wat ideetjes opdoen...

Edit: typo.

[ Voor 11% gewijzigd door Explore op 13-02-2003 13:52 ]

[Quartje]

als je phpmyadmin erop hebt staan, kan je heel makkelijk een database dump maken, en die kan je vervolgens op server B kneiteren.

[Verwijderd]

Je kunt met exec() in php shell commands uitvoeren. zo kun je :
-'pg_dump dbnaam > filenaam.dump'
-kopieeren via ssh (of ftp)
-naar de andere server hoppen via ssh
-'psql filenaam.dump < dbnaam'

[Explore]

phpmyadmin: ja, dat weet ik, maar ik wil het automatiseren, zodat het niet meer is dan een scriptje runnen...

[Explore]

Verwijderd schreef op 13 February 2003 @ 14:27:
Je kunt met exec() in php shell commands uitvoeren. zo kun je :
-'pg_dump dbnaam > filenaam.dump'
-kopieeren via ssh (of ftp)
-naar de andere server hoppen via ssh
-'psql filenaam.dump < dbnaam'

Oke, en die laatste stap? Die bevindt zich dus op server B (op 't net), kan ik die draaien vanuit server A (op 't lan)?

[Verwijderd]

Volgens mij als je naar server B ssh'd dan kun je daar gewoon weer shell commands naa toe pompen, maar ik check het nu ff....

[Verwijderd]

mmzzz, ik heb even gekeken, maar dit wordt op deze manier een lastig verhaal. het beste kun je denk ik het bestand sturen naar server B, en dan op server B in de cron een php script laten draaien die kijkt of er een dump voor hem klaarstaat, en dan dit dumpje toevoegen aan de db en dan verwijderen en weer wachten op de volgende.

[Verwijderd]

Stel je wil van A naar B:

op server B: ssh A mysqldump -A -c -Q ... databasename | mysql -B databasename

Via je ssh sessies maak je dus de dump aan op server A die je dadelijk over de ssh piped naar de mysql op server B.

Als je met ssh keys werkt zonder passwoord en een .my.cnf file gebruikt moet je zelfs niets intikken om in te loggen en te dumpen.

Zou ik wel nooit in een php scriptje doen ivm beveiliging.

[Explore]

Hm, dat met die cronjob vind ik eigenlijk ook wel erg oke. Dat valt inderdaad goed te doen.

Voorstel van Melvin spreekt me ook aan, afgezien van 't feit dat de zaak dan vanaf server B draait: vanaf 't net dus. Dan zit je inderdaad mogelijkerwijs met een security issue (al valt dat met .htaccess wel af te vangen). Alleen: hoe stel je ssh in dat je geen passwordt hoeft in te vullen? En: wordt ik daar wel blij van? Lijkt me ook een beveiligingslek.

[Verwijderd]

Wat .htaccess files ? Zet jij je database dumps in je webroot ?

En als je het van server A wil dumpen naar server B, dan draai je die lijn toch gewoon om.

[Explore]

Verwijderd schreef op 13 februari 2003 @ 15:42:
Wat .htaccess files ? Zet jij je database dumps in je webroot ?

Nee, natuurlijk niet. Maar ik heb graag dat dit proces start op commando, door semi technologie leken. Dus een webpagina is dan 't makkelijkst. En die pagina mag dan niet door zomaar idereen toegankelijk zijn. Vandaar.

En als je het van server A wil dumpen naar server B, dan draai je die lijn toch gewoon om.

Ja, dat was precies de uitleg die je hierboven gaf. Hoe zit dat met die keys?

[Verwijderd]

"man ssh" zegt niets wat ik niet kan zeggen.

[Erkens]

[rml][ ssh / putty] no password authentication[/rml]

[Verwijderd]

Ooit gehoord van replication: http://www.mysql.com/doc/en/Replication_FAQ.html ?

Of is dit niet wat je wil

[BrZ]

shellscript maken die een dump maakt en hem via ftp upload naar de andere server lijkt mij eigen het makkelijk (en die gooi je uiteraard in je crontab)

[Verwijderd]

show tables from $database
show create table $tableuiteerstequery
select * from table;
>> maak uit dit resultaat met mysql_field_name() enzo een SQL query..
$dump.= "insert into tablename (mysql_field_name()'s) VALUES (mysql_fetch_array elk element apart),(volgende record),....

enzoverder...dan ehb je toch mooie dump???

en dan PHP gebruiken via wget in een cronjob.

[ Voor 11% gewijzigd door Verwijderd op 14-02-2003 11:28 ]

[Verwijderd]

Verwijderd schreef op 13 februari 2003 @ 18:54:
Ooit gehoord van replication: http://www.mysql.com/doc/en/Replication_FAQ.html ?

Of is dit niet wat je wil

Dat is niet aan te raden als je een lage upload limiet hebt zoals adsl of kabel

[drm]

ssh A mysqldump -A -c -Q ... databasename | mysql -B databasename

Dit is toch echt de meest eenvoudige manier. Wat scheelt er aan deze oplossing, Explore?

[Explore]

Replication kende ik niet, maar ik heb net even de docs van MySQL gelezen en dit is toch niet wat ik zoek. De copy moet op commando gebeuren en niet non-stop. En daar is inderdaad nog het punt van Melvin...

Ik ben aan 't uitvogelen hoe ik ssh en scp aan de gang krijg zonder dat ik een password hoef in te voeren, zodat ik drm's methode kan uitvoeren. Die spreekt me nl. erg aan.

Wat ik nu doe is:
1. ik maak met 'ssh-keygen -t rsa' een public en private key aan
2. de public key copieer ik naar de server B in de .ssh dir van de user waarmee ik in wil loggen
3. op server B in dir .ssh: mv id_rsa.pub authorized_keys

Ik heb nog de toegangsrechten van de private en public keys nagekeken en die staan nu allemaal op user read-write.

Maar als ik nu dit probeer:

ssh serverB

dan wordt er consequent om een password gevraagd, en als ik dit probeer:

scp -B dump.sql serverB:dump.sql

dan krijg ik een foutmelding: Permission Denied.

Wat doe ik nou fout?

Btw, drm: ik werk dus liever vanuit server A, de lokale server. Punt is nu dat ik probeer vanuit server A op server B in te loggen mbv. de authentication keys. Wil niet lukken...

[Verwijderd]

Gebruik eens ssh -v voor meer info over het connecten. Heb je die key gecopieerd door die te ftp-en of scp-en, of via copy paste ? Die file moet namelijk precies overgenomen worden.

[drm]

Btw, drm: ik werk dus liever vanuit server A, de lokale server. Punt is nu dat ik probeer vanuit server A op server B in te loggen mbv. de authentication keys. Wil niet lukken...

Even voor de duidelijkheid, mijn oplossing heb ik gewoon van Melvin gecopy-paste, ik wilde er alleen nogmaals de aandacht op vestigen

In principe maakt het niet uit of je van A naar B of van B naar A dumpt, want:

code:

mysqldump [connectie naar localhost] | mysql [connectie naar andere host]
of
mysqldump [connectie naar andere host] | mysql [connectie naar localhost]

dus daar kan 't 'm niet in zitten

Zo langzamerhand begint dit overigens meer een NOS topic te worden, dus ik ga 'm even moven

[Explore]

Hm, beetje stom misschien, maar ik log in op de server als 'admin':

ssh [e-mail]

terwijl ik lokaal onder user 'root' zit.
Gaat dat goed, of moeten dat dezelfde user names zijn?

Ben inmiddels wat aan 't klooien geweest en zit nu te debuggen, via ssh -v -v
En inderdaad, de richting van 't verkeer maakt niet uit, drm.
Ik heb al de nodigde docs verslonden, maar een connectie krijg ik nog niet goed... doh!

[Verwijderd]

Moet je remote de key in de user 'admin' zn homedir zetten.

@drm: mysql [remote host] wil je meestal niet, als de mysql server op die server uberhaubt al luistert op zn externe interface en niet alleen op de loopback (zoals dat meestal is).

[drm]

@drm: mysql [remote host] wil je meestal niet

Explore wel, geloof ik ...

, als de mysql server op die server uberhaubt al luistert op zn externe interface en niet alleen op de loopback (zoals dat meestal is).

Ach, hij 's root en heeft (dus) gewoon toegang tot z'n access control list. kwestie van een externe user toevoegen die alleen vanaf server B (of A, hoe je 't maar bekijkt) in kan loggen.

[Explore]

Ik heb heel dit artikel gevolgd en uitgevoerd, maar 't werkt niet. Op 't punt waar ik de passphrase zou moeten invullen bij een connectie naar server B vanuit server A, wordt er gevraagd om een password...

Dit stukje debug log vat ik niet:

code:

debug1: identity file /root/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /root/.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1

Die 'identity' file bestaat helemaal niet op mijn systeem...

[Explore]

Ik ben er uiteindelijk uit gekomen: het is een kwestie van file en owner rechten, voor zowel de FILES als de DIRECTORY! Ik heb ze allebei op de server op 500 gezet, en toen ging 't goed.

[Explore]

Oke, ik ben inmiddels weer een stuk verder.

Ik kan nu inloggen op server B vanuit server A, zonder dat ik een password of een passphrase hoef in te voeren en dit werkt ondere elke login, interactive of niet (denk ik).

Ik werk het liefst vanuit server A (de lokale server), aangezien er andere mensen zijn die root-access hebben op server B (op 't net), die dan toegang kunnen krijgen tot mijn locale server. Ik verwacht dit niet, maar 't is toch een potentieel security leak.

Dus... vanuit server A kan ik nu 't volgende doen:

code:

mysqldump database > db.sql
scp db.sql [e-mail]:db.sql

Hierna wil ik dus hetvolgende doen:

code:

ssh [e-mail] mysql -B db.sql

Misschien niet echt effectief, aangezien er 2x een connectie moet 'domain.com' moet worden gemaakt, maar toch. Als ik die regel echter run, dan krijg ik:

bash: mysql: command not found

...hm, ik kan me vaag voorstellen dat 't path niet gezet wordt ofzo, waardoor mysql niet gevonden wordt. Normaliter hoef ik geen path mee te geven als ik inlog als 'admin'. De log zegt niet veel interessants hierover.

[Verwijderd]

dan kun je ook

code:

mysqldump database | ssh [e-mail] mysql -B -

of zo gebruiken. scheelt je weer een aantal extra commando's en files die je na afloop weer moet opruimen

[Explore]

Het was inderdaad een path probleem... Dat is opgelost. Suggestie van alexvandenzel werkt ook, welliswaar in aangepaste vorm! nifty!

Thanks all! Zo kom ik er helemaal uit...

[Explore]

De dump van A naar B werkt nu goed... Nu moet dit mini-scriptje (1 regel) worden aangeroepen vanuit PHP. Vraag is nu: onder welke user draait dit? Waarschijnlijk 'nobody'.
Ik veronderstel dat ik dan user nobody een dir moet geven:

/home/nobody/.ssh

met daarin de private keys voor de connectie naar server B...?

Klopt dit? Kan zoiets uberhaubt wel goed gaan?

Voor zover ik kan nagaan is het niet mogelijk om dat scriptje als 'root' user of evt. een andere user te draaien? En nee, apache als root draaien lijkt me niet fijn (ook al is 't op een LAN).

[ycode]

Even een regeltje tussendoor typen...

Omdat ik in dit topic niets over Replication heb gezien, vraag ik mij af, waarom hier geen gebruik van gemaakt gaat worden. Bij Replication wordt een INSERT of UPDATE op de ene database ook uitgevoerd in de andere database op de andere server. Het kan zelfs tweeweg, zodat ze elkaaars database repliceren.

Is dit niet makkelijker om te repliceren? Dat vergt 3 regels configuratie en de foutgevoeligheid ligt vele malen lager.

[Explore]

Nee, er staat in dit topic weldegelijk iets over replication.
Het is niet de bedoeling dat elke insert en update wordt gespiegeld. Dus de spiegeling moet op commando uit te voeren zijn.

Inmiddels laat ik vanuit een cronjob een php-script runnen met root-access. Dit script test of een filetje bestaat en zo ja, dan wordt die verwijderd en de dump gecopieerd. Ik ben nu aan 't checken of dit allemaal wel goed gaat en heb zo m'n twijfels. Als ik 't script los draai, dan gaat 't wel, maar vanuit de cronjob is 't twijfelachtig: de file die ik check wordt braaf verwijderd dus de cronjob wordt goed gedraaid, maar de DB op server B wordt volgens mij niet (altijd?) ge-update...

[Verwijderd]

Je moet dat niet als root draaien he, gewoon een user die mysql rechten heeft is meer dan genoeg.

[Verwijderd]

Explore schreef op 17 February 2003 @ 21:10:
Het is niet de bedoeling dat elke insert en update wordt gespiegeld. Dus de spiegeling moet op commando uit te voeren zijn.

Dat kan ook met mysql-replication:

Q: Does the slave need to be connected to the master all the time?

A: No, it does not. You can have the slave go down or stay disconnected for hours or even days, then reconnect, catch up on the updates, and then disconnect or go down for a while again. So you can, for example, use master-slave setup over a dial-up link that is up only for short periods of time. The implications of that are that at any given time the slave is not guaranteed to be in sync with the master unless you take some special measures. In the future, we will have the option to block the master until at least one slave is in sync.

Mysql-replication lijkt me een veel elegantere oplossing. Wat jij nu doet is telkens de hele database overpompen, terwijl replication alleen de verschillen bijwerkt. Maar goed, je hebt zo te zien al een oplossing gekozen.