LINUX-BG   Адрес : http://www.linux-bg.org
Накратко за репликирането в MySQL...
От: Yordan Georgiev
Публикувана на: 31-01-2005
Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=programs&key=369056964

___Преди да започнем нека да уточня, че статията е предназначена само и единствено за начинаещи. Не претендира за изчерпателност по темата, но с нейна помощ ще можете да придобиете яснота по проблема.

___Написването на тази статия бе доведено от неволите ми с репликирането. Има доста информация как става, но написана доста неразбрано. Ще ви предложа един вариант как за по-малко от 10-20 минути можете да си настроите машините и те да бъдат в пълна бойна готовност за потребителите.

___В началото нека да видим за какво служи репликирането и с какво може да ни е полезно.

___Репликирането най-просто казано е копиране на базата данни. То се осъществява като вторичен сървър непрекъснато се синхронизира с главен. Тази система от действия може да ни е полезна в няколко случая.

___Имаме едно сървърче (да се разбира машина с Линукс) с конфигуриран и стартиран MySQL демон. Независимо дали проектът ни е бил за сайт реализиран със скриптове (без значение на кой език са реализирани) или пък за някаква програма, работеща с база данни, започва да има все повече потребители. Вече се сещате, че повечето потребители водят до повече запитвания към сървъра и съответно го натоварват повече. Ако нямаме средства да закупим нова машина, която няма да се “задъхва” при натоварването, можем да разпределим натоварването между няколко по-слаби машини. Това става лесно, като от главната машина се синхронизират един или няколко вторични сървъра. Така нашето програмно приложение може да прави запитвания и към вторичната/ите машина/и, за да не се товари главната. Тука трябва да се обърне внимание на факта, че нашето софтуерно приложение трябва само да чете и в никакъв случай не трябва да прави записи на вторичния/те сървър/и. Това действие ще доведе до разминаване на копията на базата данни, защото главният сървър няма да има възможността да се синхронизира от вторичния. Това може да стане, само ако се използва клъстерна технология, но това не е тема на тази статия.

___Да си представим сега, че на същия сървър няма RAID масив и гръмне дискът върху който се намира базата ни данни. Резултатът ще е загуба на данни. Колкото и съвестни администратори да сме, правещи backup-и най-редовно, все ще загубим някаква информация, която в нашия случай може да е критично важна. Но, използвайки репликиране, ние имаме текущо копие, което се намира на друга машина. След като си оправим машината и пуснем сървъра лесно можем да си възстановим данните от копието. А през това време няма да има проблем да пренасочим потребителите към резервното копие – времето е пари и не искаме да оставяме потребителите без достъп до базата данни.

___Няма да сгрешим, ако определим този вид репликиране като пасивно. При този метод вторичните машини се синхронизират, без да се интересуват от състоянието на другите вторични машини. Вторичният сървър се интересува само от главния – има йерархична структура. Когато една репликираща система бъде реализирана на едно йерархично ниво, тя е активна. Тогава всяка машина се интересува от статуса на другите. Под статус разбираме дали машините са работещи и дали върху тях се прави запис, както и още много други състояния на машината и MySQL сървъра.

___Надявам се с дадените примери да съм разяснил в общи линии какво е репликиране. Ето и самото описание на механизма на репликирането и как се реализира в MySQL.

__Версия 3.23.33 (в някои източници пише 3.23.15) на MySQL поддържа механизъм за създаване на точни копия на база данни (репликиране). Този механизъм е реализиран с помощта на статистически файл. Както се досещате в него се записват всички действия извършени на главния сървър (затова вторичните сървъри се синхронизират спрямо главния, а главният не може да направи това от вторичните). В документацията доста ясно е казано, че на всички машини трябва да имаме една и съща версия на MySQL. Това се налага, за да нямаме нежелани проблеми, свързани с различието на версии на сървъра. И както всеки администратор би ви препоръчал – нека да използваме последната стабилна версия.

___Има вариант за използване и на различни версии на MySQL. Добре е преди всяко смесване на версиите да се обърнете към ръководството на MySQL. Естествено, за да спестим малко време, ще ви дам една извадка от последната версия на документацията, която е достъпна по време на писане на статията.
	
 		Master	Master	Master
 		3.23.33 and up	4.0.3 and up or any 4.1.x	5.0.0
 Slave	3.23.33 and up	Yes	No	No
 Slave	4.0.3 and up	Yes	Yes	No
 Slave	5.00	Yes	Yes	Yes
 
 
___Преди да започнем настройването на машините, трябва да кажем, че натоварването на главния сървър ще е значително по-голямо от това на вторичните (възможно е и главният да не е най-натоварен – всичко зависи от дизайна на проектираната от нас система, отношението на броя на записите към броя на запитванията към базата данни и още много други фактори). Поради тази причина изберете най-мощната машина за главна.

___Ето и необходимите действията, които трябва да извършим на главния сървър.


#1 Създаваме потребител на MySQL, който има права за достъп FILE за всяка база данни, която искаме да копираме. Това става така:
mysql > grant FILE on webdb.* to gigavolt@’%.domein.com’ identified by ‘pass’;
Сега потребителят gigavolt може да се свързва с главния сървър от всички субдомейни на domein.com и неговата парола е pass.

#2 Отваряме /etc/my.cnf, за да активираме функцията binlog и да изберем съответно базите данни, които искаме да се копират. Правим следното:
В секцията [mysql] добавяме
log-bin
server-id=1
И в секцията на всяка база данни, която ще репликираме добавяме bin-do-db=webdb


#3 Рестартираме MySQL за да отразим направените промени. Може да се направи с помощта на следния команден ред
root@master:/usr/local/mysql# mysqladmin shutdown && ./bin/safe_mysqld&

#4 Сега е моментът да си направим копие на директорията data/ (mysqldump няма да свърши работа, защото ни трябва цялото съдържание от директорията). Естествено преди да преминем към копирането трябва да спрем сървъра. Всичките операции могат да се реализират със следния команден ред
root@master:/usr/local/mysql# mysqladmin shutdown && tar cvf ~/data.tar data/
Описаната команда ще се изпълнява толкова продължително във времето, колкото е размерът на базите данни.

#5 Вече няма какво да човъркаме по сървъра и трябва да го стартираме
root@master:/usr/local/mysql# ./bin/safe_mysqld&


___Сега остава да направим настройките и на вторичния/те сървър/и:


#1 Копираме създадения архив и го разархивираме. Естествено, преди това спираме MySQL сървъра.
root@slave:/usr/local/mysql# mysqladmin shutdown && scp master:data.tar .
root@slave:/usr/local/mysql# mv data data.old && tar vxf ~/data.tar


#2 Задаваме на директорията data и нейното съдържание да са собственост на mysql.mysql
root@slave:/usr/local/mysql# chmod –R mysql.mysql data/

#3 Отваряме любимия ни файл /etc/my.cfn И в секцията [mysql] поставяме следното:
master-host=master.domein.com
master-user=gigavolt
master-password=pass
server-id=10
ВНИМАНИЕ всеки сървър трябва да има индивидуален server-id (не трябва да се повтарят)

#4Стартираме сървъра
root@slave:/usr/local/mysql# ./bin/safe_mysqld&

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

___При настройката на вторичните обърнете голямо внимание – всички първоначални бази данни с таблиците са преместени в data.old, за да се разархивира data.tar. Та ако имате бази данни, които са се намирали на вторичния сървър и искате да ги използвате можете да ги вземете от data.old.

___Накрая да спомена възможността да не се спира главния сървър при създаването на архива. Можете просто да спрете достъпа за писане върху базата данни на потребителите, докато трае операцията. Само да вмъкна, че има вероятност вашето софтуерно приложение да “избие” и потребителите ви ще да се изнервят от получените системни грешки. Поради тази причина препоръчвам тотално изключване на сървъра. Търсещата ви система може да създава също така темпови таблици, което пак доведе до проблеми с архива.

___Това беше. Вашите въпроси и коментари чакам с интерес 

Статията е написана специално за читателите на “Линукс за българи”
Автор: Йордан Георгиев – GigaVolt
E-mail: gigavolt@abv.bg & y.georgiev@gmail.com
WEB: http://gigavolt.hit.bg/

<< | >>

Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук, но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора, както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.

All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
Linux is copyright by Linus Torvalds.
© Линукс за българи ЕООД 2007
© Slavei Karadjov 1999 - 2006

All rights reserved.

Изпълнението отне: 0 wallclock secs ( 0.20 usr + 0.00 sys = 0.20 CPU)