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

Отказ на база данни за уебсайтове на WordPress

Всяко печелившо предприятие изисква висока наличност. Уебсайтовете и блоговете не са по-различни, тъй като дори по-малките компании и физически лица изискват сайтовете им да останат активни, за да запазят репутацията си.

WordPress е най-популярната CMS в света, която захранва милиони уебсайтове от малки до големи. Но как можете да гарантирате, че уебсайтът ви остава активен. По-конкретно, как мога да гарантирам, че недостъпността на моята база данни няма да повлияе на уебсайта ми?

В тази публикация в блога ще покажем как да постигнете отказ за вашия уебсайт WordPress с помощта на ClusterControl.

Настройката, която ще използваме за този блог, ще използва Percona Server 5.7. Ще имаме друг хост, който съдържа приложението Apache и Wordpress. Няма да докосваме частта с висока достъпност на приложението, но това също нещо, което искате да сте сигурни, че имате. Ще използваме ClusterControl за управление на бази данни, за да гарантираме наличността и ще използваме трети хост за инсталиране и настройка на самия ClusterControl.

Ако приемем, че ClusterControl е стартиран и работи, ще трябва да импортираме съществуващата ни база данни в него.

Импортиране на клъстер от база данни с ClusterControl

Отидете на опцията Импортиране на съществуващ сървър/база данни в съветника за внедряване.

Трябва да конфигурираме SSH свързаността, тъй като това е изискване за ClusterControl за да можете да управлявате възлите.

Сега трябва да дефинираме някои подробности за доставчика, версията, root потребителя достъп, самия възел и дали искаме ClusterControl да управлява автоматичното възстановяване вместо нас или не. Това е всичко, след като работата е успешна, ще ви бъде представен клъстер в списъка.

За да настроим високодостъпната среда, трябва да изпълним няколко на действията. Нашата среда ще се състои от...

  • Двойка главен – подчинен
  • Две екземпляра на ProxySQL за разделяне на четене/запис и откриване на топология
  • Два Keepalived екземпляра за управление на виртуален IP

Идеята е проста - ние ще разположим подчинения на нашия главен, така че ще имаме втора инстанция за превключване при отказ, ако главният се провали. ClusterControl ще бъде отговорен за откриването на неизправност и ще повиши подчинения, ако главният стане недостъпен. ProxySQL ще следи топологията на репликация и ще пренасочи трафика към правилния възел - записите ще бъдат изпратени до главния, без значение в кой възел се намира, четенията могат да бъдат изпратени само до главен или разпределен между главен и подчинен . И накрая, Keepalived ще бъде разпределен заедно с ProxySQL и ще предостави VIP, с който приложението да се свързва. Този VIP винаги ще бъде присвоен на един от ProxySQL екземплярите и Keepalived ще го премести към втория, ако „основният“ ProxySQL възел се провали.

Като казахме всичко това, нека конфигурираме това с помощта на ClusterControl. Всичко това може да се направи само с няколко щраквания. Ще започнем с добавянето на подчинения.

Добавяне на подчинен обект на база данни с ClusterControl

Започваме с избора на задание „Добавяне на подчинено устройство за репликация“. След това от нас се иска да попълним формуляр:

Трябва да изберем главния (в нашия случай всъщност не има много опции), трябва да предадем IP или име на хост за новия подчинен. Ако имахме предварително създадени резервни копия, бихме могли да използваме едно от тях, за да осигурим подчинения. В нашия случай това не е налично и ClusterControl ще осигури подчинения директно от главния. Това е всичко, задачата започва и ClusterControl извършва необходимите действия. Можете да наблюдавате напредъка в раздела Активност.

Накрая, след като задачата приключи успешно, подчинения трябва да се вижда на списък на клъстерите.

Сега ще продължим с конфигурирането на ProxySQL екземплярите. В нашия случай средата е минимална, така че, за да опростим нещата, ще намерим ProxySQL на един от възлите на базата данни. Това обаче не е най-добрият вариант в реална производствена среда. В идеалния случай ProxySQL би бил разположен или на отделен възел, или съвместно с другите хостове на приложения.

Мястото да започнете работата е Управление -> Балансиране на натоварване.

Тук трябва да изберете къде да бъде инсталиран ProxySQL, да подадете административни идентификационни данни и добавете потребител на база данни. В нашия случай ще използваме нашия съществуващ потребител, тъй като нашето WordPress приложение вече го използва за свързване с базата данни. След това трябва да изберем кои възли да използваме в ProxySQL (тук искаме и главен, и подчинен) и да уведомим ClusterControl дали използваме изрични транзакции или не. Това всъщност не е уместно в нашия случай, тъй като ще преконфигурираме ProxySQL, след като бъде внедрен. Когато тази опция е активирана, разделянето на четене/запис няма да бъде активирано. В противен случай ClusterControl ще конфигурира ProxySQL за разделяне на четене/запис. В нашата минимална настройка трябва сериозно да помислим дали искаме да се случи разделянето на четене/запис. Нека анализираме това.

Предимствата и недостатъците на Spit за четене/запис в ProxySQL

Основното предимство на използването на разделянето за четене/запис е, че целият SELECT трафик ще бъде разпределен между главния и подчинения. Това означава, че натоварването на възлите ще бъде по-малко и времето за реакция също трябва да бъде по-малко. Това звучи добре, но имайте предвид, че ако един възел се повреди, другият възел ще трябва да може да поеме целия трафик. Няма смисъл да има автоматично преминаване при отказ, ако загубата на един възел означава, че вторият възел ще бъде претоварен и де факто също недостъпен.

Може да има смисъл да разпределите натоварването, ако имате няколко подчинени устройства - загубата на един възел от пет е по-малко въздействаща от загубата на един от двама. Без значение какво решите, можете лесно да промените поведението, като отидете на възел ProxySQL и щракнете върху раздела Правила.

Уверете се, че сте разгледали правило 200 (това, което улавя всички изрази SELECT ). На екранната снимка по-долу можете да видите, че целевата хост група е 20, което означава, че всички възли в клъстера - разделяне на четене/запис и мащабиране е активирано. Можем лесно да деактивираме това, като редактираме това правило и променим целевата хостгрупа на 10 (тази, която съдържа master).

Ако искате да активирате разделянето за четене/запис, можете лесно направете това, като редактирате това правило за заявка отново и зададете целевата хостгрупа обратно на 20.

Сега нека внедрим втория ProxySQL.

За да избегнем повторно предаване на всички опции за конфигурация, можем да използваме „Импортиране на конфигурация ” и изберете нашия съществуващ ProxySQL като източник.

Когато тази задача приключи, все още трябва да извършим последната стъпка в настройката на нашата среда. Трябва да разположим Keepalived върху екземплярите на ProxySQL.

Разгръщане на Keepalived върху екземпляри на ProxySQL

Тук избрахме ProxySQL като тип балансиране на натоварването, преминахме и двата екземпляра на ProxySQL за Keepalived за инсталиране и написахме нашия VIP и мрежов интерфейс.

Както можете да видите, вече имаме цялата настройка и готова. Имаме VIP от 10.0.0.111, който е присвоен на един от ProxySQL екземплярите. ProxySQL екземплярите ще пренасочат нашия трафик към правилните бекенд MySQL възли и ClusterControl ще следи средата, извършвайки отказ, ако е необходимо. Последното действие, което трябва да предприемем, е да преконфигурираме Wordpress, за да използва виртуалния IP за свързване с базата данни.

За да направим това, трябва да редактираме wp-config.php и да променим променливата DB_HOST на нашия виртуален IP:

/** MySQL hostname */

define( 'DB_HOST', '10.0.0.111' );

Заключение

Отсега нататък Wordpress ще се свързва с базата данни чрез VIP и ProxySQL. В случай, че главният възел се повреди, ClusterControl ще извърши преодоляването на отказ.

Както можете да видите, нов главен е избран и ProxySQL също сочи към нов господар в хост групата 10.

Надяваме се, че тази публикация в блога ви дава някаква представа за това как да проектирате среда на база данни с висока достъпност за уебсайт на Wordpress и как ClusterControl може да се използва за разгръщане на всички негови елементи.


  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/MariaDB сървър

  2. MySQL в облака - онлайн миграция от Amazon RDS към вашия собствен сървър:Част 2

  3. Как да избегнем деленето на нула в MySQL

  4. Връщане на ResultSet

  5. Кога да използвате единични кавички, двойни кавички и обратни кавички в MySQL