«
»

Replikacja baz MySQL

Konfiguracja replikacji w skrócie:

  • MASTER

W sekcji [mysqld] w pliku konfiguracyjnym (my.cnf) dodać / zmienić następujące linie:

log-bin = mysql-bin
server-id = 1

Pierwsza to nazwa pliku, w którym zapisywane są binarne logi operacji na bazie (dopełniona sześcioma cyframi, np. mysqld-bin.000036), druga, to identyfikator serwer. Ważne, żeby był różny na obu serwerach i na serwerze MASTER wyższy.

Następnie za pomocą GRANT należy nadać odpowiednie uprawnienia:

SQL> GRANT REPLICATION SLAVE ON *.* TO <user>@<host> IDENTIFIED BY ‘<passwd>’;

Teraz trzeba działać szybko:

SQL> FLUSH TABLES WITH READ LOCK;
SQL> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000001
Position: 98
Binlog_Do_DB:
Binlog_Ignore_DB:

1 row in set (0.00 sec)

Pierwszą komendą zablokowaliśmy tablice przed zapisem, żeby nikt nie zmienił żadnych danych, druga pokazuje nam w jakim stanie jest MASTER – istotna jest nazwa pliku oraz pozycja (które zapytanie się wykonało).

Kolejny krok, to wyłączenie bazy, skopiowanie danych (katalogi w datadir i pliki InnoDB), uruchomienie bazy i wykonanie:

SQL> UNLOCK TABLES;

MASTER gotowy i może dalej pracować.

  • SLAVE

W pliku my.cnf, w sekcji [mysqld] wpisujemy:

server-id = 2

Kopiujemy dane z serwera MASTER, uruchamiamy bazę i włączamy w tryb SLAVE:

SQL> CHANGE MASTER TO MASTER_HOST=’<host>’, MASTER_USER=’<user>’, MASTER_PASSWORD=’<passwd>’, MASTER_LOG_FILE=’<filename>’, MASTER_LOG_POS=<position>;
SQL> START SLAVE;

W pierwszym poleceniu podajemy odpowiednie wartości, drugie zaczyna replikować dane i voilà!

Uwagi końcowe:

  1. Warto od czasu do czasu czyścić logi binarne za pomocą PURGE MASTER LOGS, np:

    2. PURGE MASTER LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

    Jeżeli wierzymy, że replikacja zawsze będzie działać, ew. monitorujemy to wystarczająco często, to można posiłkować się zmienną expire_logs_days, by zautomatyzować proces czyszczenia logów.

  2. Zalecane jest, by monitorować stan serwera SLAVE za pomocą:

    3. SHOW SLAVE STATUS\G

    Interesujące dane to
    Seconds_Behind_Master – powinno zawsze wynosić 0, jeśli nie, to szukamy Last_Error.

  3. Replikację dobrze zaplanować we wczesnej fazie projektu. Zanim baza rozrośnie się do niebotycznych rozmiarów (długie kopiowanie i downtime) i będzie krytyczną (np. osiem milionów serwerów musi jednocześnie z niej korzystać).

Do replikacji nie trzeba jakoś specjalnie przekonywać: failover i load-balancing same nas przekonają. Więcej do poczytania na stronie MySQL AB (czy jak kto woli – Sun).

Tagi:

Ten wpis został opublikowany środa, 9 Lipiec 2008 o 10:16 i jest zaszufladkowany do kategorii MySQL. Możesz śledzić wszystkie odpowiedzi do tego wpisu poprzezkanał RSS 2.0. Możesz dodać odpowiedź lub trackback ze swojej strony.

Dodaj odpowiedź