Mysql
 sql >> база данни >  >> RDS >> Mysql

Важни проверки на здравето за вашите MySQL сървъри с реплики

При настройка на MySQL източник-реплика с висока достъпност (HA) е важно непрекъснато да наблюдавате здравето на сървърите източник и реплики, за да можете да откривате потенциални проблеми и да предприемате коригиращи действия . В тази публикация в блога ние обясняваме някои основни проверки на здравето, които можете да направите на вашия MySQL източник и възли за реплика, за да сте сигурни, че настройката ви е здрава. Програмата или скриптът за наблюдение трябва да предупреждава рамката за висока наличност в случай, че някоя от проверките на състоянието не успее, което позволява на рамката за висока наличност да предприеме коригиращи действия, за да гарантира наличността на услугата.

Проверки на състоянието на MySQL Source Server

Препоръчахме вашата програма или скриптове за наблюдение на изходния MySQL да се изпълняват на чести интервали. Ако приемем, че скриптът за наблюдение работи на същия сървър като вашия MySQL сървър, можете да проверите за следното:

  1. Уверете се, че услугата MySQL работи

    Това може да стане с помощта на проста команда като:

    > pgrep mysqld

    ИЛИ

    >service mysqld status
  2. Уверете се, че можете да се свържете с MySQL и да направите проста заявка

    Препоръчахме да имате кратко време за изчакване за тези команди, за да можете бързо да откриете дали MySQL не реагира. Това може да се постигне чрез обаждане като:

    /usr/bin/timeout 5 mysql -u testuser -ptestpswd -e 'select * from mysql.test’

    Уверете се, че сте проверили изходната стойност на горната команда:

    Стойност на излизане=0 ⇒ Успех

    Изходна стойност=1 ⇒ Неуспех

    Exit-value=124 ⇒ Време за изчакване

    Ако командата изтече, това означава, че услугата MySQL не реагира достатъчно. Съветваме ви да опитате отново след известно време, за да избегнете фалшиво отрицателни резултати. Ако изходният код показва грешка, кодът за връщане от MySQL ще ни каже причината за неуспеха. Един пример за неуспех е грешката „Твърде много връзки“ от MySQL, която се случва, ако броят на връзките към сървъра надвиши вашата конфигурационна стойност „max_connections“.

  3. Уверете се, че източникът на MySQL работи в режим четене-запис

    Можете да използвате следната команда, за да сте сигурни, че източникът на MySQL работи в режим четене-запис:

    /usr/bin/timeout 5 mysql -u testuser -ptestpswd -e "SELECT @@global.read_only"

    Очаква се източникът винаги да работи в режим четене-запис и следователно стойността на  read_only трябва да бъде „ИЗКЛЮЧЕНО“.

    Възможно е също така да обединим тази стъпка със стъпка 2 и вместо да правим тестовата заявка 'select * от mysql.test, можем просто да направим заявката, за да получим read_only стойност.

Важни проверки на здравето за вашите сървъри MySQL Source-ReplicaClick To Tweet

Проверки на състоянието на MySQL Replica Server

Можете да стартирате мониторинга за вашите MySQL реплики на по-малка честота в сравнение с източника, тъй като те не обработват запис на данни. Първите 3 стъпки за проверката на състоянието на вашата реплика могат да бъдат същите като тази на източника, с изключение на това, че трябва да гарантираме, че репликата работи в режим само за четене - стойността на променливата read_only трябва да бъде „ON“ в стъпка 3 .

Освен това можем да направим повече проверки на репликата, за да гарантираме, че състоянието на репликацията е здраво, като например:

  1. Репликата е конфигурирана да се копира от десния източник.

  2. Връзката на репликата с източника е изправна.

  3. Репликата е в състояние да приложи изходните събития, които е получила.

Възможно е да проверите за всичко по-горе с помощта на командата „покажи състоянието на репликата“. Например:

mysql> show replica status \G;

*************************** 1. row ***************************

Replica_IO_State: Waiting for source to send event

Source_Host: 172.31.17.43

Source_User: repl_user

Source_Port: 3306

Connect_Retry: 10

Source_Log_File: mysql-bin.000001

Read_Source_Log_Pos: 7510

Relay_Log_File: relay-log.000006

Relay_Log_Pos: 414

Relay_Source_Log_File: mysql-bin.000001

Replica_IO_Running: Yes

Replica_SQL_Running: Yes

******************Truncated*********************************
  • Стойността Source_Host показва, че изходният сървър е конфигуриран за репликация.

  • За стойността Replica_IO_Running, „Да“ показва, че репликата се е свързала с източника и получава репликационния поток.

  • За стойността Replica_SQL_Running „Да“ показва, че приложението на репликата работи и може да приложи всички събития, получени от източника.

В тази публикация в блога обсъдихме някои прости проверки, които могат да открият дали има основни проблеми във вашия MySQL източник и сървъри за реплики. Като цяло механизмът за откриване на неизправности при настройка с висока наличност е сложен предмет и се нуждае от стабилна рамка за висока наличност, чрез която трябва да се внедри наблюдението на проверката на състоянието. Можете да научите повече за подробностите на нашата рамка за висока достъпност в нашата обяснена рамка за висока достъпност на MySQL – Част I:Въведение в блог публикация.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MySQL не може да добави ограничение за външен ключ

  2. MySQL ЗАРЕЖДАНЕ НА ДАННИ INFILE с ПРИ АКТУАЛИЗИРАНЕ НА ДУБЛИРАН КЛЮЧ

  3. Проверка на таблица за припокриване на времето?

  4. Грешка в MySQL/Writing File (Errcode 28)

  5. Cronjob или MySQL събитие?