Zaczniemy od momentu gdy serwer ID 1 (192.168.100.166) nie działa, a na serwerze ID 2 (192.168.100.167) zaimportowałam dane z dump-a. Zobaczymy co się stanie gdy serwer ID 1 ponownie zacznie działać.
Przy pomocy polecenia SHOW SLAVE STATUS widzimy, że połączenie do jego mastera nie może zostać nawiązane:
mysql (root@ela_db)> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 192.168.100.166
Master_User: replication
Master_Port: 3309
Connect_Retry: 60
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 1171
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 1314
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1171
Relay_Log_Space: 1464
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2003
Last_IO_Error: error connecting to master 'replication@192.168.100.166:3309' - retry-time: 60 retries: 86400
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
1 row in set (0.02 sec)
Po podniesieniu serwera, replikacja sama zaczęła nawiązywać połączenie:
140124 05:49:02 mysqld_safe Starting mysqld daemon with databases from /home/mysql/mysql5.5/myisam 140124 5:49:02 [Note] Plugin 'FEDERATED' is disabled. 140124 5:49:02 InnoDB: The InnoDB memory heap is disabled 140124 5:49:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins 140124 5:49:02 InnoDB: Compressed tables use zlib 1.2.3 140124 5:49:02 InnoDB: Using Linux native AIO 140124 5:49:02 InnoDB: Initializing buffer pool, size = 128.0M 140124 5:49:02 InnoDB: Completed initialization of buffer pool 140124 5:49:02 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 140124 5:49:02 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 140124 5:49:02 InnoDB: Waiting for the background threads to start 140124 5:49:03 InnoDB: 1.1.8 started; log sequence number 1601052 140124 5:49:03 [Note] Recovering after a crash using /home/mysql/mysql5.5/replication/binlog 140124 5:49:03 [Note] Starting crash recovery... 140124 5:49:03 [Note] Crash recovery finished. 140124 5:49:04 [Note] Slave SQL thread initialized, starting replication in log 'binlog.000003' at position 502, relay log '/home/mysql/mysql5.5/replication/relay-bin.000002' position: 250 140124 5:49:04 [Note] Event Scheduler: Loaded 0 events 140124 5:49:04 [Note] /usr/local/mysql5.5/bin/mysqld: ready for connections. Version: '5.5.23-log' socket: '/tmp/mysql5.5.sock' port: 3309 MySQL Community Server (GPL) 140124 5:49:04 [Note] Slave I/O thread: connected to master 'replication@192.168.100.167:3309',replication started in log 'binlog.000003' at position 502 140124 5:49:07 [Note] Start binlog_dump to slave_server(1), pos(binlog.000005, 1171)
Na serwerze, który został podniesiony, zaczęły napływać dane:
Gdzie:
- Master_Log_File - nazwa binlog-u mastera, która jest aktualnie czytana przez slave
- Read_Master_Log_Pos - pozycja z binlog-u mastera, która jest aktualnie czytana
- Relay_Log_File - nazwa aktualnego relay log-u
- Relay_Log_Pos - aktualna pozycja z relay log-u (wszystkie zamiany sprzed tej pozycji, zostały już wykonane w bazach slave)
- Relay_Master_Log_File - nazwa binlog-u mastera, gdzie zmiana z relay logu była czytana
- Exec_Master_Log_Pos - pozycja z binlog-u mastera, która właśnie została wykonana
- Seconds_Behind_Master - ile sekund slave jest do tyłu w stosunku do mastera
Gdy już wszystkie dane zostały wyrównane, chcieli byśmy usunąć zbędne binlog-i. Może nam w tym pomóc polecenia: PURGE BINARY LOGS, SHOW BINARY LOGS oraz zmienne serwerowe.
Zmienne expire_logs_days, mówi po ilu dniach binary log będzie usuwany. Jeśli wartość zmiennej ustawiona jest na 0, mechanizm usuwania jest wyłączony i wymagane jest usuwanie binary logów ręcznie.
mysql (root@ela_db)> show variables like 'expire_logs_days'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | expire_logs_days | 0 | +------------------+-------+ 1 row in set (0.00 sec)
Polecenie SHOW BINARY LOGS zwraca listę binary logów z ich rozmiarem (maksymalny rozmiar jest ustawiany przez zmienną max_binlog_size), a przy pomocy PURGE BINARY LOGS (dokumentacja: http://dev.mysql.com/doc/refman/5.5/en/purge-binary-logs.html) możemy usunąć stare pliki:
mysql (root@ela_db)> show binary logs; +---------------+------------+ | Log_name | File_size | +---------------+------------+ | binlog.000001 | 26372 | | binlog.000002 | 938077 | | binlog.000003 | 1073879253 | | binlog.000004 | 1074045928 | | binlog.000005 | 1073749134 | | binlog.000006 | 725494868 | +---------------+------------+ 6 rows in set (0.00 sec) mysql (root@ela_db)> PURGE BINARY LOGS to 'binlog.000006'; Query OK, 0 rows affected (0.44 sec) mysql (root@ela_db)> show binary logs; +---------------+-----------+ | Log_name | File_size | +---------------+-----------+ | binlog.000006 | 725494868 | +---------------+-----------+ 1 row in set (0.00 sec)
Jeśli chodzi o relay logi w zależności od ustawień serwera, mogą one być np automatycznie usuwane gdy są już nie używane:
mysql (root@(none))> show variables like '%relay%'; +-----------------------+--------------------------------------------+ | Variable_name | Value | +-----------------------+--------------------------------------------+ | max_relay_log_size | 0 | | relay_log | /home/mysql/mysql5.5/replication/relay-bin | | relay_log_index | | | relay_log_info_file | relay-log.info | | relay_log_purge | ON | | relay_log_recovery | OFF | | relay_log_space_limit | 0 | | sync_relay_log | 0 | | sync_relay_log_info | 0 | +-----------------------+--------------------------------------------+ 9 rows in set (0.82 sec)
- relay_log_purge - włączone lub wyłączone automatyczne usuwanie relay logu gdy już będzie niepotrzebny
- relay_log_recovery - gdy włączony, przy starcie serwera relay log jest automatycznie 'pobierany' z serwera mastera dla plików jeszcze niesprocesowanych
- max_relay_log_size - maksymalny rozmiar relay log plików. Jeśli jest on ustawiony na 0, rozmiar jest definiowany przez zmienną max_binlog_size
- relay_log - ścieżka pod którą możemy znaleźć pliki
- relay_log_index - nazwa używana dla pliku indexu relay logów
- relay_log_info_file - nazwa pliku w którym slave zapisyje informacje o relay logach.
- relay_log_space_limit - całkowity limit rozmiaru w bajtach wszystkich relay logów na slave. Jeśli jest ustawione na 0 - oznacza, że nie ma limitu. Dobrze jest ustawić na dostępną powierzchnię dyskową, bo gdy limit zostanie przekroczony, wątek I/O przestanie czytać zdarzenia z binary logi z mastera, dopóki SQL wątek nie dogoni i nie usunie jeszcze niesprocesowanych relay logów.
I jeszcze kilka poleceń
Aby zobaczyć listę slave-ów możemy użyć polecenia:
mysql (root@ela_db)> show slave hosts; +-----------+------+------+-----------+ | Server_id | Host | Port | Master_id | +-----------+------+------+-----------+ | 1 | | 3309 | 2 | +-----------+------+------+-----------+ 1 row in set (0.00 sec)
Podglądanie zmian w binlogach (polecenie show binlog events):
mysql (root@ela_db)> show binlog events in 'binlog.000008' from 257826769; +---------------+-----------+-------------+-----------+-------------+--------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +---------------+-----------+-------------+-----------+-------------+--------------------------------+ | binlog.000008 | 257826769 | Query | 2 | 257826852 | BEGIN | | binlog.000008 | 257826852 | Table_map | 2 | 257826934 | table_id: 52 (ela_db.test) | | binlog.000008 | 257826934 | Update_rows | 2 | 257827880 | table_id: 52 | | binlog.000008 | 257827880 | Update_rows | 2 | 257828522 | table_id: 52 flags: STMT_END_F | | binlog.000008 | 257828522 | Xid | 2 | 257828549 | COMMIT /* xid=5097300 */ | +---------------+-----------+-------------+-----------+-------------+--------------------------------+ 5 rows in set (0.00 sec)
Podgląd relay logów:
mysql (root@ela_db)> SHOW RELAYLOG EVENTS IN 'relay-bin.000034' from 250 limit 10; +------------------+------+-------------+-----------+-------------+----------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+------+-------------+-----------+-------------+----------------------------+ | relay-bin.000034 | 250 | Query | 1 | 163761726 | BEGIN | | relay-bin.000034 | 333 | Table_map | 1 | 163761808 | table_id: 93 (ela_db.test) | | relay-bin.000034 | 415 | Update_rows | 1 | 163762754 | table_id: 93 | | relay-bin.000034 | 1361 | Update_rows | 1 | 163763700 | table_id: 93 | | relay-bin.000034 | 2307 | Update_rows | 1 | 163764646 | table_id: 93 | | relay-bin.000034 | 3253 | Update_rows | 1 | 163765592 | table_id: 93 | | relay-bin.000034 | 4199 | Update_rows | 1 | 163766538 | table_id: 93 | | relay-bin.000034 | 5145 | Update_rows | 1 | 163767484 | table_id: 93 | | relay-bin.000034 | 6091 | Update_rows | 1 | 163768430 | table_id: 93 | | relay-bin.000034 | 7037 | Update_rows | 1 | 163769376 | table_id: 93 | +------------------+------+-------------+-----------+-------------+----------------------------+ 10 rows in set (0.00 sec)
To tak szybko o replikacji. Jeśli pewne rzeczy były nie jasne, odsyłam do posta wprowadzającego: Instalacja servera i replikacji master-master w MySQL v5.5. Jeśli macie jakieś pytania to komentujcie.
Brak komentarzy:
Prześlij komentarz