= bubbalog =Дневникът на моето стадо

UildShiiP Cluster Project: Свъраване и проблеми по модулите

Saturday 10.10.2009 16:18 EET · Публикувано от в = Cluster =, = FreeBSD =, = HA-cluster =

След като завърших и двата модула – Apache2 HA Cluster и MySQL HA Cluster – дойде време да свържа 2-та компонента в една работеща система. Както се подразбира обаче, това също се оказа задачка не за няколко минутки, но поне научих няколко нови неща, които никой не ме беше предупредил, че могат да се случат толкова лесно, ако не се внимава… става дума за това, колко е лесно да се изкарат от синхронизация двата SQL сървъра и колко нерви и пссуване поеха докато се вкарат пак обратно в работен режим. Та така, двете задачки са – подсигуряване на достъп до определена база данни от друг сървър и самото обвързване на Apache с MySQL, и решаването на някои проблеми с излезлите от синхрон нодове на MySQL клюстъра.

Отдалечен достъп до MySQL – MySQL Remote Access

1. Разрешаване на достъп през мрежата

По подразбиране достъпа до базите данни в MySQL е охраничен само до localhost от съображения за сигурност, така че ако се налага странично приложение или външен сървър да използват бази данни на вашия MySQL сървър това трябва да се подсигури допълнително. Първата стъпка е да проверим дали в /etc/my.cnf не е блокирана мрежата – това става с коментирането на реда

#ee /etc/my.cnf
# Don’t listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the “enable-named-pipe” option) will render mysqld useless!
#
#skip-networking

който е отговорен за блокирането на мрежата.  Запазете и рестартирайте сървъра

#/usr/local/etc/rc.d/mysql-server restart

2. разрешаване на достъп до база данни на отдалечен сървър

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

# mysql -u root -p
mysql> create database databasename;
mysql> grant all privileges on databasename.* to potrebitel@IP_na_otdalechen_server identified by “parola”;

3. Отваряне на порт във firewall-а и тестване на връзката

След всичко изброено до ту трябва разбирасе да разрешите на защитната стена да пропуска заявките до самия сървър, както и да тествате после дали всичко е наред и дали отдалечения всървър има реално позволение за работа. За това как да се разреши работата в защитната стена няма да споменавам, а самия тест е достатъчно прост:

#mysql -u potrebitel –h 192.168.200.100 –p

Командата се изпълнява разбира се на отдалечения сървър, където вече се появява и още един нов параметър -h, който оказва датабаза сървъра към който искаме да се свържем. С това работата засега е приключена. От тук натам започва вече същинската работа по самоя клъстър – да се сглоби всичко това в една работеща система която да върши все пак нямамква работа, зашити теорията е едно, но практиката си е друго…

Проблеми със синхронизацията на MySQL

Когато има работа с бази данни от изключителна важност е бекъп нода на клъстъра да е постоянно в синхрон със своя мастер, за да може във всеки един момент при проблем да заеме неговото място. Именно и това е критичния момент който трябва да се избегне, но и трябва човек да е готов за да може да реагира бързо иначе последиците може да се окажат голяма боза, или недай си боже – загуба на клиентски данни, което е фатално вече. През няколкото дни в които експериментирах по свързването за радост или не успях да се вкарам в няколко премеждия които според мен бяха не съвсем безполезни.

Начините да се изкара клъстъра от равновесие и синхрон не са малко. Като започне с простото изскубване на мрежовия кабел и свършим с много по-сериозни проблеми чието решение граничи с пълна преинсталация. Един от тези проблеми, с който и основно се заиграх и заради него започнах с ученето по отстраняване на проблеми се оказа една настройка за отдалечения достъп на MySQL сървъра, която се оказа крайно несъвместима с CARP – параметър в my.cnf в който се оказва на кой адрес да слуша сървъра

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306

bind-address = 65.55.55.2
# skip-networking

Използването на този параметър се оказа крайно неприятно поради неизвестни за мен причини и трайно изкара на няколко пъти (първия път случайно, другите нарочно) репликацията от синхрон. За самото връщане на репликацията към синхрон се порових доста и намерих няколко команди, които в долупосочения ред или не точно помогнаха, така че не гарантирам за някаква строгоопределена последователност като само рамката на занятието остава една и съща.

Дали реплицацията е в синхрон може да проверите на всеки от нодовете със следната команда от промпта на mysql

mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.100.202
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000006
Read_Master_Log_Pos: 98
Relay_Log_File: node1-8rc1-relay-bin.000014
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000006
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

1 row in set (0.00 sec)

и в изведената информация потърсите следните 2 реда

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Когато двата са във вида който р показан значи всичко е наред, обаче ако поне единия от тези редове е с No – значи нещо не е наред и репликацията не работи. По време на самата процедура в по-лесния вариант не се налага спиране на MySQL сървъра което съответно няма да се забележи от потребителя и няма да внесе някакво неудобство за него, но понякога и това е наложимо колкото и да е неприятно.

1. Показване на кой е master-а

Първата стъпка е спиране на бекъп часта на всеки от сървърите

mysql> stop slave;

след което може да пристъпим към синхронизирането на самата репликация. Самите сървъри се синхронизират чрез бинарни логове и позицията от която започват (поне дотолкова разбрах от четенето ми, не претендирам за някаква особена компетентност), като това което е посочено за слейва като бинарен лог и позиция трябва да е същото и на неговия мастер. За да проверите кой е сегапния логи позиция проверете мастер статуса на всеки от нодовете

mysql> show master status;
+——————+———-+————–+——————+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000005 |       98 |              |                  |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

Следващия ход е да кажем на всеки от нодовете за това кой е бинарния лог и позицията на неговия сървър

mysql> change master to master_host=’IP_na_master’, master_user=’replica’, master_password=’slave’, master_log_file=’mysql-bin.000005′, master_log_pos=98;

като замените master_log_file и master_log_pos с показанията от предната команда. Стартирайте бекъпите на двата нода  и рестартирайте сървърите

mysql> start slave;
mysql> exit
#/usr/local/etc/rc.d/mysql-server restart

и проверете дали този път двата реда които посочих предималко са с Yes положение. Ако да – след малко (зависи от големината на базите данни) двата нода ще се синхронизират, ако не – продължаваме борбата натам… Лично при мен първия път когато изкарахо нодовете от синхрон това ми помогна, но втория и третия и натам борбата беше доста по-трудна и упорита и е описана накратко по-надолу.

2. Ръчна синхронизация

ВНИМАНИЕ! Това не е много препоръчително и трябва да се извърши само ако наистина знаете какво правите и какви са последствията от вашите действия! При неправилна работа това може да предизвика тотално объркване и загуба на данни! Следващия пример описан по-долу е пробван от мен на тестови постановка, не нося отговорност ако нещо се оплеска!

При варианта за синхронизиране на базите данни на ръка вече ще се наложи обаче да се прекрти замалко услугата в зависимост от големината на базите данни например. Идеята е освен да се покаже кои са файловете според които да се синхронизират нодовете да с синхронизират на ръка и самите бази данни на двата нода. За да се избегнат разминавания и междинни записи в базите при този случай е необходимо да се заключат самите бази данни

mysql> flush tables with read lock;
mysql> exit

след което правим пълен бекъп на всички бази данни на активния и работщ нод и ги копираме на този, който се опитваме да поправим, ресторваме ги, а после направим това и обратно за да са и двата нода с еднакви бази данни на едно ниво

#mysqldump -u root -p –all-databases > allbases.sql
#scp /usr/home/username/allbases.sql user@IP_na_drugiq_nod:allbases.sql
#mysql -u root -p < allbases.sql

а след това отключим наново базите за достъп

mysql> unlock tables;

3. Изтриване на бинарните логове

Докато четях по разни блогове се появи и опцията за изтриване на самите бинарни логове. Това се прави като се спрат MySQL сървърите на двата нода и се изатрият всички такива.

#/usr/local/etc/rc.d/mysql-server stop
#cd /var/db/mysql/
# rm *-bin.*
#/usr/local/etc/rc.d/mysql-server start

което би предизвикало евентуално резултата от следващата подточка.

4. Ресетване на репликацията

Третия вариант който намерих случайно е ресетване на самата репликация с поредицата от следните 3 команди в промпта на mysql на двата нода при което се принуждава всеки слейв да прочете наново информацията от неговия мастер.

mysql> stop slave;
mysql> reset slave;
mysql> start slave;

И това е, тези примери за оправяне на синхронизацията всичките с опитани от мен на тестова постановка и са ми помогнали един по един или в комбинация на един с друг, както споменах бая се заиграх от нямане какво да правя. В никакъв случай не претендирам, че темата е изчерпана и че правя нещата правилно, но мисля, че е добра отправна точка за учене. Както казах и по-горе, ползвайте писаното внимателно, не отговарям за нанесени ети при ползването на моя материал.

Остави коментар

Писането на кирилица е задължително!
Коментари, които не са на кирилица ще бъдат изтрити без предупреждение.
Всеки коментари съдържащи 1 или повече линка, ще бъдат публикувани след одобрение.