Van egy LAMP szerverem sok adattal, amit költöztetnék egy másik gépre.
Az adatbázis átvitele tűnik egyedül problémásnak.
- Az új környezetet ki lehet alakítani a régivel kompatibilis módon.
- A fájlokat átálláskor rsync-kel elég gyorsan másolhatók.
- A névszerverfrissülésből származó kavarodást is meg lehet úszni, ha a költözés után a forrás szerverhez már nem lehet hozzáférni, az már csak a beérkező kérelmeket továbbítja az új irányba.
- Egyedül az adatbázisok gyors átvitele nem triviális.
Erre most leggyorsabb megoldási ötletem, hogy a régi és új mysql szervert MASTER-SLAVE replikációba kapcsolom, majd költözés után az új adatbázis önállóan üzemel tovább, a régi meg lekapcs.
Ez optimális módja a költözésnek, vagy van valamilyen buktató, amire még jó vigyázni, netán van ennél is gyorsabb? Mondjuk, egy MASTER-MASTER LAMP replikáció lenne az ideális, de hát ugye az nincs.
- 1244 megtekintés
Hozzászólások
Mennyi időd van a leállásra? LAMP esetén azért nem üzleti kritikus a cucc annyira, hogy 2x fél óra ne lenne megoldható...
mysqldump és betöltés a másik oldalon mennyi idő? Az nem fér bele? A master-slave replikáció a kezdő másolást annyi ideig, vagy tovább fogja csinálni, mint egy dump
- A hozzászóláshoz be kell jelentkezni
Szeretném minimalizálni az állásidőt. Az lehet, hogy a kezdő másolást sokáig csinálja, de az elmehet bőven az üzemelés alatt, így a leállás max 10 perc lenne, bár szerintem még annál is kevesebb.
Hogy megéri-e 60 perc állás helyett 10 percért szívni, azt még nem tudom. Egyelőre a lehetőségeimet szeretném átlátni.
- A hozzászóláshoz be kell jelentkezni
Akkor előbb próbáld ki a dumpolást a másik gépen. Megtudod mennyi ideig tartana.
- A hozzászóláshoz be kell jelentkezni
Gondolom ezt pontosan tudja, mivel valahogy csak menti a szervet.
- A hozzászóláshoz be kell jelentkezni
Nem biztos, hogy dumppal menti. Sőt, ha jót akar magának, akkor nem azzal menti.
- A hozzászóláshoz be kell jelentkezni
Régen csináltam:
MYSQL ugyanaz a verzió, ugyanaz a disztrib. rsync folyamatosan, majd a mind a két helyen mysql stop ekkor még egy rsync ami már nagyon keveset írt, aztán induláskor már az új szerver ment.
- A hozzászóláshoz be kell jelentkezni
Hány domain-t szolgált ki?
Ha sok, akkor lehet részleges költözést csinálni, mivel DNS módosítás is időbe telik. Mi úgy költöztettünk több domain-os rendszert, hogy
0. Új vas teljesen felkonfigurálva, kezdeti adatok betöltve ( fut a LAMP)
1. FS rsync folyamatosan
2. Régi vason a domain kikonfigurálás, majd dump készítés
3. DNS módosítással párhuzamosan dump visszatöltés az új vason
4. goto 2 amíg az összes át nem költözik
- A hozzászóláshoz be kell jelentkezni
Köszi, ez valahogy eszembe sem jutott. Pedig triviális.
Tényleg lehetne akár domainenként is költözni, és akkor az egy költözés ideje minimális.
- A hozzászóláshoz be kell jelentkezni
Én még annyit csinálnék a 2. pontnál, hogy mondjuk az adott domaint proxy-znám az új vas felé (ha ez nincs benne a "kikonfigurálásban" persze). Mivel a DNS átállásának lesz olyan hatása, hogy még a régi vasra is esnek be, és a dump nem lesz feltétlen naprakész.
Vagy az új vason a DB-t tényleg SLAVE-ként felkonfolni a régire ezen segíthet. De egy MASTER-MASTER még jobb lenne (egyébként simán meg lehet oldani), mert lehet olyan eset, hogy a SLAVE-en elvégzett művelet ütközik a régi DB-re (MASTER) beérkezett adatművelettel, és szétesik a replikáció. Ilyen esetben újra el lehet egyébként indítani, és jó eséllyel minden konzisztens lesz, de nagy számú hibánál azért felmerülhetnek kétségek.
Mindehhez hozzá tartozik persze, hogy webhostingban a SELECT a legnagyobb számú művelet, így azért kisebb a kockázat.
- A hozzászóláshoz be kell jelentkezni
Egy szerver nem szerver, érdemes eleve HA-sra megcsinálni, és akkor a költöztetés triviális :).
- A hozzászóláshoz be kell jelentkezni