Mysql replikáció egy számítógépen, mysql
Figyelmeztetés. Ha nem ismeri a replikációt mysql, nem valószínű, hogy észre semmit nizhenapisannogo, akkor először olvassa el a dokumentációt a replikáció és a multi-server mysql fut ugyanazon a számítógépen.
Prelude. Két rendes adatbázis-replikációt szervezett két ugyanazon a gépen futó mysql kiszolgálón (a myisam-táblák lezárásának megkerülésével). Itt semmi bonyolultnak és különlegesnek tűnik, mivel tudom, hogyan kell több mysql kiszolgálót futtatni egy gépen, és hogyan kell szervezni az adatbázis-replikációt két különböző gép között. De a feladat nem volt a legkönnyebb. Nem fogom elmondani, hogyan küzdöttem a konfigurációval egész nap, hány indítási lehetőséget próbáltam stb. de csak írj a buktatókról:
Vízalatti kő №1. A MySQL-nek a master-host, master-port paraméterei vannak, de nincs master-socket paraméter, tehát amikor az első kiszolgálóra írtam
master-host = localhost
master-port = 3307,
nem ragaszkodott a 127.0.0.1: 3307-hez, hanem a / tmp / mysql.sock-hoz, azaz. magára és nem a második kiszolgálóra. És a naplókban arról a helyről, ahol valóban tapad, véletlenül csak akkor jelent meg, amikor nagyon nahimichil voltam.
A probléma megoldása a master-host = 127.0.0.1.
Víz alatti kő szám 2. Még miután megváltoztattam a master-host-ot 127.0.0.1-re a my.cnf-ben, a rendszer nem működött. Itt az az oka, hogy az opció master-host és néhány más replikációs paraméterek olvasni a fő konfigurációs csak akkor, ha valami baj van a fájl master.info (akkor automatikusan létre az adatok könyvtárban), például, egyszerűen hiányzik, és ha létezik, akkor a mester-gazda olvasható innen, és a kiszolgálót beillesztettem a my.cnf fájlba. A dokumentáció ezt mondja, de azt találtam, miután kipróbáltam ... Vörös bíbor betűkkel kellett kiemelnem.
A probléma megoldása a manuális szerkesztés, vagy ami könnyebb, távolítsa el a master.info-t, anélkül, hogy elfelejtené a mysql szervert ezt megelőzően. Az eltávolításkor az operációs infa elveszik - az aktuális naplófájl - tehát óvatosnak kell lenni, biztonságosabb szerkeszteni.
Mi történt a végén. Itt van egy darab my.cnf, amely releváns az ügyben, amellyel minden jól működik (mysql 4.0.18 verziója):
################
# MySQL kiszolgáló 1
[Mysqld1]
port = 3306
socket = /tmp/mysql.sock
datadir = / data / mysql1
pid-file = /data/mysql1/mysqld.pid
user = mysql
# replikáció
log-bin
server-id = 1
binlog-do-db = teszt
master-host = 127.0.0.1
master-port = 3307
master-user = replikátor
master-connect-retry = 10
replicate-do-db = teszt
################
################
# MySQL kiszolgáló 2
[Mysqld2]
port = 3307
socket = /tmp/mysql2.sock
datadir = / data / mysql2
pid-file = /data/mysql2/mysqld.pid
user = mysql
# replikáció
log-bin
server-id = 2
binlog-do-db = teszt
master-host = localhost
master-port = 3306
master-user = replikátor
master-connect-retry = 10
replicate-do-db = teszt
################
Az első szerveren:
GRANT REPLICATION SLAVE ON *. * Replikátor @ localhost;
a második:
GRANT REPLICATION SLAVE ON *. * A repliká[email protected];
A teljesítményről (a lezárás helyett). Amint láthatja, a második kiszolgálónál elhagytam a master-host = localhost parancsot. akkor csatlakozik a /tmp/mysql.sock fájlhoz, azaz. az első kiszolgálóhoz, és oda kell mennünk. Úgy tűnik, hogy az Unix tartományon keresztül kétszer gyorsabban, mint a hálózati aljzatokon keresztül történő csere. Alig ez nagymértékben befolyásolja a replikáció teljesítményét, különösen mivel a legtöbb esetben két különböző gép között valósul meg a hálózat. De ennek ellenére zavarba ejtő, hogy a mysql fejlesztői nem vették igénybe a replikáció esetét egyetlen számítógépen, és nem hajtották végre a master-socket paramétert.