Używam MySQL-5.1.50 z konfiguracją replikacji Master-slave.

Przez większość czasu niewolnik pozostaje w tyle za panem.

Kiedy uruchamiam show processlist;, nie ma zapytania, które zajmuje dużo czasu. Włączyłem slow_logrównież. Nie znajduje jednak żadnego wolno działającego zapytania.

Slave stale ostrzega, że ​​replikacja jest kilka sekund za masterem. Czasami czas opóźnienia wzrasta.

Jak zdiagnozować przyczynę problemu?

Potrzebuję pilnej pomocy, ponieważ problem ten utrzymuje się przez ostatnie 20 dni.

Seconds_Behind_Master jest naprawdę jak przeglądanie przeszłości za pomocą podróży w czasie.

Pomyśl o tym w ten sposób:

• Słońce znajduje się 93 000 000 mil od Ziemi
• Prędkość światła wynosi 186 000 mil / s
• Prosty podział pokazuje, że światło Słońca dociera do Ziemi w przybliżeniu 500 sekund (8 min 20 sekund)
• Kiedy patrzysz na Słońce, tak naprawdę nie widzisz Słońca. Widzisz, gdzie to było 8 min 20 sekund temu.

Podobnie wydaje się, że Master przetwarza wiele zapytań jednocześnie.

Spoglądasz wstecz na Slave, biegnij SHOW SLAVE STATUS\Gi mówi 200 za Seconds_Behind_Master. Jak obliczana jest ta liczba? Czas zegara Slave'a (UNIX_TIMESTAMP (NOW ()) - TIMESTAMP zapytania, kiedy zostało zakończone i zapisane w Dzienniku Binarnym Mistrza.

Jest jeszcze jedna miara, na którą warto zwrócić uwagę Seconds_Behind_Master. Ta metryka nazywa się Relay_Log_Space. To reprezentuje sumę wszystkich bajtów dla wszystkich plików przekaźników w Slave. Domyślnie największy pojedynczy dziennik przekazywania jest ograniczony do 1 GB. Jeśli Relay_Log_Spacejest mniejszy niż 1 GB, oznacza to, że wiele długo działających zapytań wykonywanych równolegle na Master. Niestety, ze względu na jednowątkowy wątek replikacji SQL, zapytania są wykonywane jeden za drugim.

Załóżmy na przykład, że masz następujący scenariusz na Master:

• Dziennik powolnych zapytań jest włączony
• 20 zapytań wykonywanych równolegle na Master
• Każde zapytanie zajęło 3 sekundy
• Każde zapytanie jest rejestrowane w głównym dzienniku binarnym z tym samym znacznikiem czasu

Kiedy Slave odczytuje te zapytania ze swojego dziennika przekazywania i przetwarza je jeden po drugim

• Zegar Niewolnika będzie się poruszał
• TIMESTAMP dla każdego z 20 zapytań będzie identyczny
• różnica wzrośnie o 3 sekundy zostanie zakończone zapytanie
• powoduje to 60 sekund dla Seconds_Behind_Master

Jeśli chodzi o Slow Log, domyślna wartość parametru long_query_time wynosi 10 sekund. Jeśli wszystkie twoje zapytania w dziennikach przekazywania są krótsze niż 10 sekund, nigdy nie złapiesz niczego w Dzienniku powolnych zapytań.

Mam następujące zalecenia dla serwerów Master i Slave

• ZALECENIE # 1 : Uaktualnij do MySQL 5.5 . W MySQL 5.5 i Percona Server 5.1.38+ można dostroić InnoDB, aby uzyskać dostęp do wielu procesorów. Pisałem o tym wcześniejsze posty
  • Apr 26, 2012: Czy wydajność procesora jest istotna dla serwera bazy danych?
  • Sep 20, 2011: Wiele rdzeni i wydajność MySQL
  • Sep 12, 2011: Czy można zmusić MySQL do korzystania z więcej niż jednego rdzenia?
  • May 26, 2011: O wydajności baz danych jednowątkowych i wielowątkowych
• ZALECENIE # 2 : Użyj InnoDB dla wszystkich tabel . InnoDB buforuje dane i indeksy w pamięci RAM, MyISAM buforuje tylko indeksy.
• ZALECENIE # 3 : Zwiększ pamięć RAM . Musisz buforować więcej danych i indeksów zarówno dla Slave, jak i Master
• ZALECENIE # 4 : Dostrój wszystkie zapytania. Zmniejszenie milisekund z zapytań uruchamianych setki razy znacznie zmniejsza Seconds_Behind_Master.

DALSZE ROZWIĄZYWANIE PROBLEMÓW

Jeśli chcesz zobaczyć zapytania powodujące opóźnienie replikacji, wykonaj następujące czynności:

• SHOW SLAVE STATUS\G
• Uzyskaj nazwę dziennika przekazywania od Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• W systemie operacyjnym cd /var/lib/mysqllub w dowolnym miejscu, w którym zapisywane są dzienniki przekazywania
• Zrzuć dziennik przekazywania do pliku tekstowego

Na przykład Zróbmy SHOW SLAVE STATUS\G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.149
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 1024035856
               Relay_Log_File: relay-bin.000030
                Relay_Log_Pos: 794732078
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           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: 1024035856
              Relay_Log_Space: 794732271
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451149

Jeśli ucieknę STOP SLAVE; START SLAVE; , dziennik przekaźników zamyka się, a nowy jest otwarty. Ale ty chcesz relay-bin.000030.

Zrzuć zawartość w następujący sposób:

cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt

Teraz możesz zobaczyć zapytania, które Slave aktualnie przetwarza. Możesz użyć tych zapytań jako punktu wyjścia do strojenia.

Jakiego formatu binarnego dziennika używasz? Czy używasz ROW lub STATEMENT?
„SHOW GLOBAL VARIABLES LIKE 'binlog_format'; ”

Jeśli używasz ROW jako formatu binlog, upewnij się, że wszystkie tabele mają klucz podstawowy lub unikalny:
SELECT t.table_schema,t.table_name,engine FROM information_schema.tables t INNER JOIN information_schema .columns c on t.table_schema=c.table_schema and t.table_name=c.table_name and t.table_schema not in ('performance_schema','information_schema','mysql') GROUP BY t.table_schema,t.table_name HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

Jeśli wykonasz np. Jedną instrukcję usuwania na masterie, aby usunąć 1 milion rekordów z tabeli bez PK lub unikalnego klucza, wówczas tylko jedno pełne skanowanie tabeli zostanie wykonane po stronie master, co nie ma miejsca w przypadku slave.
Gdy używany jest ROW binlog_format, MySQL zapisuje zmiany wierszy w dziennikach binarnych (nie jako oświadczenie takie jak STATEMENT binlog_format) i ta zmiana zostanie zastosowana w bocznym rzędzie slave'a wiersz po rzędzie, co oznacza, że ​​nastąpi 1 milion pełnych skanów tabeli na urządzeniu podrzędnym, aby odzwierciedlić tylko jedną instrukcję usuwania na urządzeniu nadrzędnym, co powoduje problem z opóźnieniem urządzenia podrzędnego.

Wartość seconds_behind_master w STATUSIE POKAŻ SLAVE jest różnicą między czasem systemowym w systemie głównym, który został zapisany, gdy zdarzenie zostało pierwotnie wykonane i zapisane w dzienniku binarnym ... a czasem systemowym w urządzeniu slave, gdy zdarzenie zostanie tam wykonane.

Sekundy za masterem podadzą nieprawidłowe wartości, jeśli zegary dwóch systemów nie są zsynchronizowane.