Я використовую MySQL-5.1.50 з налаштуванням реплікації Master-slave.

Більшу частину часу раб відстає від господаря.

Коли я бігаю show processlist;, немає запиту, який займає тривалий час. Я також включив slow_log. Однак він не знаходить жодного повільно запущеного запиту.

Раб постійно подає попередження про те, що реплікація на секунди відстає від ведучого. Іноді час затримки збільшується.

Як діагностувати причину проблеми?

Мені потрібна термінова допомога, оскільки ця проблема зберігається останні 20 днів.

The Seconds_Behind_Master насправді схожий на перегляд минулого через подорож у часі.

Подумайте про це так:

• Сонце знаходиться на відстані 93 000 000 миль від Землі
• Швидкість світла 186 000 миль / сек
• Просте ділення показує, що світло Сонця досягає приблизно 500 секунд (8 хв 20 сек)
• Дивлячись на Сонце, ви насправді не бачите Сонця. Ви бачите, де це було 8 хв 20 сек тому.

Таким же чином, здається, що Майстер обробляє багато запитів одночасно.

Ти озираєшся на Раба, біжиш, SHOW SLAVE STATUS\Gі це говорить 200 за Seconds_Behind_Master. Як обчислюється ця кількість? Час Slave's Clock (UNIX_TIMESTAMP (NOW ()) - TIMESTAMP запиту, коли він був завершений і записаний у бінарний журнал Master.

Крім того, є ще одна метрика, на яку слід звернути увагу Seconds_Behind_Master. Ця метрика називається Relay_Log_Space. Це являє собою суму всіх байтів для всіх ретрансляційних файлів на підлеглому. За замовчуванням найбільший одиночний журнал реле обмежений 1 Гб. Якщо Relay_Log_Spaceменше 1 ГБ, це вказує на те, що багато тривалих запитів виконуються на Майстрі паралельно. На жаль, завдяки однопотоковому потоку SQL реплікації запити виконуються один за одним.

Наприклад, припустимо, у вас є такий сценарій у програмі Master:

• Увімкнено журнал повільних запитів
• 20 запитів, виконаних паралельно на Майстрі
• Кожен запит займав 3 секунди
• Кожен запит записується в головний бінарний журнал з однаковою міткою часу

Коли підлеглий читає ці запити зі свого журналу ретрансляцій та обробляє їх по черзі

• Рабський годинник буде рухатися
• TIMESTAMP для кожного з 20 запитів буде ідентичним
• різниця збільшуватиметься на 3 секунди заповнення запиту
• це призводить до 60 секунд протягом Seconds_Behind_Master

Щодо Повільного журналу, типовий параметр long_query_time - 10 секунд. Якщо всі ваші запити в журналах ретрансляції становлять менше 10 секунд, ви ніколи не зафіксуєте нічого в журналі повільних запитів.

У мене є такі рекомендації як для Master, так і Slave серверів

• РЕКОМЕНДАЦІЯ №1 : Оновлення до MySQL 5.5 . У розділі MySQL 5.5 та Percona Server 5.1.38 ++ ви можете налаштувати InnoDB для доступу до декількох процесорів. Я писав про це минулі пости
  • Apr 26, 2012: Чи відповідає ефективність процесора для сервера баз даних?
  • Sep 20, 2011: Багатоядерні та продуктивність MySQL
  • Sep 12, 2011: Чи можна змусити MySQL використовувати більше одного ядра?
  • May 26, 2011: Про ефективність однопотокових та багатопотокових баз даних
• РЕКОМЕНДАЦІЯ №2 : Використовуйте InnoDB для всіх таблиць . InnoDB кешує дані та індекси в оперативній пам'яті, MyISAM кешує лише індекси.
• РЕКОМЕНДАЦІЯ №3 : Збільшити ОЗУ . Ви повинні кешувати більше даних та індексів на Рабі і Магістра
• РЕКОМЕНДАЦІЯ №4 : Налаштування всіх запитів. Скорочення мілісекунд від запитів, які виконуються в сотні разів, проходить довгий шлях до зменшення Seconds_Behind_Master.

ДОПОМОГА ЗАБЕЗПЕЧЕННЯ

Якщо ви хочете побачити запити, що викликають відставання реплікації, виконайте наступне:

• SHOW SLAVE STATUS\G
• Отримайте назву журналу ретрансляції Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• В ОС cd /var/lib/mysqlабо там, де записуються журнали ретрансляції
• Скиньте журнал реле до текстового файлу

Наприклад, зробимо 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

Якщо я запускаю STOP SLAVE; START SLAVE;, журнал ретрансляції закривається і відкривається новий. Тим не менш, ти хочеш relay-bin.000030.

Вивантажте вміст так:

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

Тепер ви можете бачити запити, які підлеглий зараз намагається обробляти. Ви можете використовувати ці запити як вихідну точку налаштування.

Який бінарний формат журналу ви використовуєте? Використовуєте ви ROW або STATEMENT?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

Якщо ви використовуєте ROW як формат бінарного файлу, переконайтеся, що всі ваші таблиці мають первинний або унікальний ключ:
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;

Якщо ви виконаєте, наприклад, одне твердження про видалення на ведучому для видалення 1 мільйона записів на столі без ПК або унікального ключа, то з боку майстра буде проведено лише одне сканування повної таблиці, що не є випадком у веденому.
Коли використовується ROW binlog_format, MySQL записує зміни рядків у двійкові журнали (не як вираз, як STATEMENT binlog_format), і ця зміна буде застосована до бічного ряду рядка за рядком, що означає, що відбудеться повне сканування 1 мільйона таблиці. на підлеглому відображати лише одне твердження про видалення на ведучому і це спричиняє проблему відставання в рабовласництві.

Значення second_behind_master в STOW SLAVE STATUS - це різниця між системним часом на майстрі, який зберігається, коли подія спочатку виконувалася і записувалася у бінарний журнал ..., і системним часом на підлеглому, коли подія виконується там.

Секунди позаду master дадуть неправильні значення, якщо годинник двох систем не синхронізується.