Jó kis program, hasznos azoknak, akik lusták, mint én. ugye a megadott kulcsot másolja be a távoli szerver megadott user-ének authorized-key -ébe, és a tetjébe még a jogosultságokat is szépen beállítja.
Ha nem a standard 22-es porton megy a linux, akkor pedig az alábbi megoldást használhatjuk:
ssh-copy-id "user@host -p 7786"
it works…
MySQL adatbáziskezelő szerver esetén lehetőségünk van replikikációra, azaz az adatokst módosító (beszúrás, update, törlés, stb.) szinte azonnali továbbítására kerülnek egy távoli szerverre is, így az adatokon végzett módosítások ott is végrehajtásra kerülnek.
A megoldás ugyan elég távol áll egy terhelés-eolsztásos clustertől (A master node-ot írni és olvasni is tudjuk, de a slave-et csak olvasni), de ettől haszna még bőven akad:
Egyszerű failover megoldásnak tekinthető: Ha a master szerver elhasal, az adatok gyakorlatilag real time ott vannak a slave-en, csak meg kell neki mondani, hogy Ő mostantól nem slave.
Ha túl sok, vagy túl nagy adatbázisaink vannak, akkor a mysqldump-os megoldás problémás lehet a nagy erőforrásigény, a hosszú mentési idő, és a még hosszabb visszaállítási idő miatt. Ilyen esetben célszerű az adatfájlok közvetlen mentése. Tekintettel arra, hogy a MySQL szerver működése során memóriába pufferel adatokat, ha egy futó MySQL szerver alól kimentjük az adatfájlokat, korántsem biztos hogy minden adat a fájlban lesz, illetve hogy az adatfájl egyáltalán használható lesz egy visszaállítás után. Kézenfekvő a megoldás: slave szerverre replikáljuk az adatokat, majd mentés előtt a slave szervert leállítjuk. Szolgáltatásunk működését ez nem befolyásolja, hisz a kliensek továbbra is a master szerverrel kommunikálnak, a master pedig a binlogban gyűjti, azokat az utasításokat, amelyeket a slave-nek végre kell hajtania, hogy újra az aktuális állapotot tükrözze. A leállított slave adatfájljait ezután gond nélkül menthetjük, majd a mentés végzetével a slave adatbázis szerver ujraindításával minden megy tovább.
A master – slave replikáció megvalósítása: