Linux за българи: Форуми

Здравейте,

Имам следната ситуация която трябва да реша:
 * 3 MySQL сървъра с информация която се обновява регулярно (~100 - 500 write query-та на час)
 * и трите сървъра са бекенд на едно и също приложение (намират се на 3 различни места)
 * информацията трябва да се опреснява на определен период от време (изискване от клиента)
 * няма явно изразен master сървър
 * има изрично изискване сървърите да не са перманентно свързани/достъпни.

Въпросът:
Как да организирам репликацията? Мислех си нещо със копиране на binlog-а и после наливането му като всеки за малко го правя slave, но не знам до колко е удачно.

moin,

ако пишеш и на трите машини в MySQLите - бая зор ще е. Особено ако не можеш да бръкнеш в приложението. Имам подобна задачка, която мисля от 2 години и не мога да измисля адекватно. Не се досещам за база, която да може да преглътне нещо такова. Напоследък ми се въртят еротични идеи на тема нормални клъстерни решения, ама и там все удрям на нещо, дето не е точно както аз го искам. Май ще мигрирам на MS Windaaz...

Have Phun!

Прочутата книжка "High Performance MySQL" на O'Reilley дава предложение да се организира пръстен в който едновременно всеки сървър е master и slave.

Сега остава да се реши дали Ще издържи системата ако slave-овете се закачат на да речем 8 часа по веднъж през BTK Adsl към master-ите.

Мене ми е малко по-интересно дали трите инстанции на базата не могат да ползват някакъв shared storage? Разбира се, това би наложило и съответната клъстерна файлова система вероятно, особено при положение че заявки има към всеки от трите сървъра. Но това според мен е едно решение, което би спестило доста тарапана..

Едит: уфф те били географски оталечени, хммм кофти...не че няма разни iSCSI варианти, ама производителността ще го отнесе..а и да подкарваш клъстерна фс върху интернет...с тези амплитуди на мрежовата латентност...чудя се колко ли често разни GFS/OCFS nodes ще се fence-ват заради таймаути в I/O заявките си, голямо шоу ще бъде на ден по няколко пъти да караш хората на майната си да ти вдигат сървърите хехе

За голяма съжаление MySQL не може да изпълни задачата, ако има прекъсване на връзката. Ние се борим с тази задача вече 3 години и няма еднозначно решение. Това, което сме постигнали най-добре е следното:

1. Един Master, който гарантирано работи винаги и връзката е сигурна;
2. Няколко Slave (в нашия случай около 40), които са на не много надеждна връзка;
3. Приложение, което работи на машината на Master-a и което проверява следните параметри:
а) Дали има Ping към Slave, всички Slave кoмпютри трябва да са с реално IP;
б) Същото приложение, след успешен Ping проверява дали работи Slave MySQL сървъра;
в) Същото приложение, след успешна проверка проверява дали работи репликацията работи. Често Slave сами си изключват репликацията и не е ясно защо се получава така. Дори и при безумни параметри Retries и Timeout;
г) Периодично се прави преброяване на редовете на таблиците, защото дори и при работеща српликация - данните се разсинхронизират.

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

Има решение и то е работещо за това да има отделни сървъри и те да нямат пряка връзка през 100% от времето, но не е с MySQL...

Нещо се мешат термините. Репликиране (или реплициране, който както иска да си го транскрибира) не може да същетвува на 8 часа. Или по-точно не е ама изобщо смислено решение. За 500 записа на час, за 3 машини/сървъра, за един работен ден (8 часа) е мнооого по-размно да се напише един Убав скрипт.

Може да накараш софтуера ти да пише в две таблици едновременно. Основната и тази, която искаш да се копира и на другите сървъри (втората таблица е, за да не мислиш много). Останалото е само хитър начин на експорт и импорт.

А с репликация на 8 часа без мастер (та дори и с главен сървър) може да очакваш засиране на терена.