SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 03.08.2007 12:38:35

Golova
Завсегдатай
Зарегистрирован: 23.03.2007
Сообщений: 92

fail over in mysql replication

как организовать сие  на примере двух серверов (master, slave), что бы было что то вроде:
master - конечно же является основным на начальном этапе, пишет себе в bin log, а slave забирает накопленые данные.
Но вот вышел казус - master по каким либо причинам загнулся(сбой в питании, mysql server вылетел) и нам нужно переключится на slave.
Вот тут возникают вопрос:
Допустим мы перевели наши приложения на соединение со slave, но данные то пишутся... и после подъема master сервера нужно как то обратно перейти. Как теперь быть с этой репликацией (данные на slave новее чем на master) ?

Может есть какие то отработаные сценарии по этому поводу?

Неактивен

 

#2 03.08.2007 12:53:38

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6740

Re: fail over in mysql replication

1. Писать на слейве бинлоги мастера
2. В случае отказа мастера, писать на слейва
3. Поднятого мастера цеплять не мастером, а слейвом

А для HA можно использовать кластер smile

Неактивен

 

#3 03.08.2007 13:20:20

Golova
Завсегдатай
Зарегистрирован: 23.03.2007
Сообщений: 92

Re: fail over in mysql replication

простите, что такое 'HA' ??

Неактивен

 

#4 03.08.2007 15:01:30

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6740

Re: fail over in mysql replication

High Availability

Неактивен

 

#5 04.09.2007 22:28:39

ksm
Участник
Зарегистрирован: 04.09.2007
Сообщений: 7

Re: fail over in mysql replication

Golova написал:

как организовать сие  на примере двух серверов (master, slave), что бы было что то вроде:
master - конечно же является основным на начальном этапе, пишет себе в bin log, а slave забирает накопленые данные.
Но вот вышел казус - master по каким либо причинам загнулся(сбой в питании, mysql server вылетел) и нам нужно переключится на slave.
Вот тут возникают вопрос:
Допустим мы перевели наши приложения на соединение со slave, но данные то пишутся... и после подъема master сервера нужно как то обратно перейти. Как теперь быть с этой репликацией (данные на slave новее чем на master) ?

Может есть какие то отработаные сценарии по этому поводу?

Посмотрите в сторону circular replication, появившийся в 5.1. Там каждый сервер и мастер и слейв

Неактивен

 

#6 04.09.2007 23:01:15

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

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

Традиционная репликация, в том числе круговая - асинхронная. В случае круговой репликации, если писать на обе машины, то нужно вручную разбираться с тем, чтобы не возникло повторяющихся уникальных id при одновременной записи на оба сервера.

Для бесперебойной работы оптимально использовать кластер (работающий по принципу синхронной репликации). Запись не завершится, пока все реплики в рамках кластера не будут содержать обновленную информацию. В случае выхода из строя одной машине, все продолжает работать без изменений. После восстановления машины, она сама принимает текущее состояние данных в кластере.

Неактивен

 

#7 04.09.2007 23:52:59

ksm
Участник
Зарегистрирован: 04.09.2007
Сообщений: 7

Re: fail over in mysql replication

rgbeast написал:

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

Традиционная репликация, в том числе круговая - асинхронная. В случае круговой репликации, если писать на обе машины, то нужно вручную разбираться с тем, чтобы не возникло повторяющихся уникальных id при одновременной записи на оба сервера.

Для бесперебойной работы оптимально использовать кластер (работающий по принципу синхронной репликации). Запись не завершится, пока все реплики в рамках кластера не будут содержать обновленную информацию. В случае выхода из строя одной машине, все продолжает работать без изменений. После восстановления машины, она сама принимает текущее состояние данных в кластере.

Вручную разбираться с автоинкрементыми id не приходится при выставлении auto-increment-increment, auto-increment-offset. Задержка при репликации конечно есть, однако все зависит от профиля приложения - при редкой записи и частных чтениях это решение вполне работоспособно. Да и можно принудительно заставлять например перед записью на слейве синхронизироваться с мастером. Кроме того, не нужно ничего менять в структуре самих бд и данных.

Синхронный кластер требует больше ресурсов на тоже приложение, перевод структуры данных в NDB (а там еще есть свой список ограничений), большой RAM (чтобы уместить все индексируемые данные), оптимизацию запросов под маленькие транзакции и паралелльное исполнение. Кроме того в зависимости от кол-во реплик HA может и не быть (NoOfReplicas=1). Это имеет смысл лишь при высоконагруженных серверах и/или имеющих необходимость в очень высоком уровене HA.

Неактивен

 

#8 05.09.2007 00:09:29

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

ksm написал:

Синхронный кластер требует больше ресурсов на тоже приложение, перевод структуры данных в NDB (а там еще есть свой список ограничений), большой RAM (чтобы уместить все индексируемые данные), оптимизацию запросов под маленькие транзакции и паралелльное исполнение. Кроме того в зависимости от кол-во реплик HA может и не быть (NoOfReplicas=1). Это имеет смысл лишь при высоконагруженных серверах и/или имеющих необходимость в очень высоком уровене HA.

Чтобы добиться минимального HA, кластер должен состоять по крайней мере из трех машин. Однако, в описанной схеме круговой репликации, третья машина тоже неявно присутствует - это арбитр, который детектирует сбой и перенаправляет клиентов. В случае круговой репликации, автоматически решаются только проблемы auto_increment полей, просто уникальные id и внешние ключи остаются под ответственностью клиента. Транзакции в случае круговой репликации невозможны. Получается, что ниша для круговой репликации остается в случае если ровно 2 машины и требуются возможности MyISAM.

Неактивен

 

#9 05.09.2007 00:41:09

ksm
Участник
Зарегистрирован: 04.09.2007
Сообщений: 7

Re: fail over in mysql replication

rgbeast написал:

Чтобы добиться минимального HA, кластер должен состоять по крайней мере из трех машин. Однако, в описанной схеме круговой репликации, третья машина тоже неявно присутствует - это арбитр, который детектирует сбой и перенаправляет клиентов.

Аналогично и для кластера в случае вылетания одного из mysqld. Никакой приципиальной разницы со стороны клиента. А нормально работает схема выбора сервера на клиенте.

rgbeast написал:

В случае круговой репликации, автоматически решаются только проблемы auto_increment полей, просто уникальные id и внешние ключи остаются под ответственностью клиента. Транзакции в случае круговой репликации будут невозможны.

Транзакции в случае круговой репликации работают, а в NDB не работают foreign keys. Конечно частью проблем придется управлять на уровне алгоритма, однако в случае с кластером - проблем будет еще больше именно по перписыванию логики, начиная от обработчиков для temporary errors, которые могут возникнуть везде и являются вполе легитимными, отсутствие fulltext индексов, ограничение по памяти данных и т.д. 

Получается для замены циркулярной репликации нужно еще +2 машины для DN (mgmd можно поднять везде - он почти не берет ресурсов). Это существенно, при том что на малых объемах данных кластер еще и проиграет в скорости myisam/innodb только из-за накладных расходов по передаче данных на data nodes.

Неактивен

 

#10 05.09.2007 00:56:57

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

ksm написал:

Транзакции в случае круговой репликации работают

Не могу представить себе как они работают. Какая будет изоляция, если одна транзакция на одном мастере, другая - на другом.

ksm написал:

начиная от обработчиков для temporary errors, которые могут возникнуть везде и являются вполе легитимными, отсутствие fulltext индексов, ограничение по памяти данных и т.д.

В 5.1 данные кластера можно хранить на диске. Fulltext доступно только в MyISAM и работает нормально только на английском языке. Внешние ключи для всех движков появятся в 6.0.

ksm написал:

Получается для замены циркулярной репликации нужно еще +2 машины для DN (mgmd можно поднять везде - он почти не берет ресурсов). Это существенно, при том что на малых объемах данных кластер еще и проиграет в скорости myisam/innodb только из-за накладных расходов по передаче данных на data nodes.

Не совсем точно - достаточно всего 3 машины. На двух ndb-ноды, на третьей - mgmd, SQL-ноды на каждой машине. По производительности во многих случаях проиграет, а во многих случаях выйграет. Все зависит от структуры запросов.

Если говорить на сегодня, то в кластере 5.0 очень много ограничений. 5.1 до сих пор бета, хотя обещают релиз до конца года.

Неактивен

 

#11 05.09.2007 01:23:08

ksm
Участник
Зарегистрирован: 04.09.2007
Сообщений: 7

Re: fail over in mysql replication

rgbeast написал:

ksm написал:

Транзакции в случае круговой репликации работают

Не могу представить себе как они работают. Какая будет изоляция, если одна транзакция на одном мастере, другая - на другом.

Так собственно, транзакция попадает в бинлог по коммиту или ролбаку. А там она уже оформлена. Кстати, кластер поддерживает всего один уровень изоляции.

rgbeast написал:

В 5.1 данные кластера можно хранить на диске. Fulltext доступно только в MyISAM и работает нормально только на английском языке. Внешние ключи для всех движков появятся в 6.0.

Да, данные в 5.1 можно хранить на диске - но это касается только неиндексируесых полей. Если поле присутствует в индексе, оно автоматом попадает в память.

Fulltext действительно только в майсаме, однако от этого не легче, если на этом построена работа какого-то приложения и из-за переноса в NDB, нужно менять алгоритм.

Про внешние ключи поговорим, когда они реально появятся, сейчас же при переносе приложения с внешними ключами в NDB нужно также менять алгоритм и встраивать свой контроль целостности.

rgbeast написал:

ksm написал:

Получается для замены циркулярной репликации нужно еще +2 машины для DN (mgmd можно поднять везде - он почти не берет ресурсов). Это существенно, при том что на малых объемах данных кластер еще и проиграет в скорости myisam/innodb только из-за накладных расходов по передаче данных на data nodes.

Не совсем точно - достаточно всего 3 машины. На двух ndb-ноды, на третьей - mgmd, SQL-ноды на каждой машине. По производительности во многих случаях проиграет, а во многих случаях выйграет. Все зависит от структуры запросов.
Если говорить на сегодня, то в кластере 5.0 очень много ограничений. 5.1 до сих пор бета, хотя обещают релиз до конца года.

Установка Mysdqld и dn на одну машину крайне не рекомендуется из-за снижения общей производительности, в силу того, что data node загружает и процессор и память. В результате получим конкуренцию за ресурсы.

Отредактированно ksm (05.09.2007 01:24:57)

Неактивен

 

#12 05.09.2007 02:19:08

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

ksm написал:

Так собственно, транзакция попадает в бинлог по коммиту или ролбаку. А там она уже оформлена. Кстати, кластер поддерживает всего один уровень изоляции.

Если конфликтующая транзакция выполнялась на втором мастере, то обе транзакции будут успешными, но будет ошибка репликации или несогласованные данные. Поэтому я бы говорил про транзакции, только если на одном из мастеров запрещена запись. В багтрекере было много ошибок, связанных с бинлогом при транзакциях на разных уровнях изоляции. Получается, что не все уровни изоляции совместимы с репликацией, если используется query-based репликация.

Какой подход выбрать зависит от конкретного случая и от выбранного подхода к разработку приложений.

Неактивен

 

#13 05.09.2007 10:54:23

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

ksm написал:

Это существенно, при том что на малых объемах данных кластер еще и проиграет в скорости myisam/innodb только из-за накладных расходов по передаче данных на data nodes.

В соседней теме практическая ситуация, в которой кластер работает медленнее (возможно из-за багов в ndb или неправильной конфигурации) http://sqlinfo.ru/forum/viewtopic.php?pid=675

Неактивен

 

#14 05.09.2007 11:56:29

ksm
Участник
Зарегистрирован: 04.09.2007
Сообщений: 7

Re: fail over in mysql replication

rgbeast написал:

ksm написал:

Так собственно, транзакция попадает в бинлог по коммиту или ролбаку. А там она уже оформлена. Кстати, кластер поддерживает всего один уровень изоляции.

Если конфликтующая транзакция выполнялась на втором мастере, то обе транзакции будут успешными, но будет ошибка репликации или несогласованные данные. Поэтому я бы говорил про транзакции, только если на одном из мастеров запрещена запись.

Опять же не вижу большой разницы с кластером. Если есть две mysqld ноды подключенные к кластеру и на обоих стартуют транзакции (например с тем же самым PK для какой-то таблицы), то отработает только первая, закончившая транзакцию. Вторая отобьется с ошибкой.  Единственное, что в случае асинхр. репликации из-за ошибки SLAVE_THREAD встанет, что опять же лечится стартом с другой позиции или пропуском данного куска.

Тем не менее circluar replication - это весьма недорогой способ получить повышение HA без серьезных вложений и изменений структуры данных БД. Это просто следующий шаг после обычного mysqld сервера при росте нагрузки и увеличении требование к HA (и даже распределению нагрузки). Кстати, вполне успешно работают схемы и 3-4 серверов по кругу. А вот уже следующий шаг - кластер (а потом возможно и репликация кластеров).

Отредактированно ksm (05.09.2007 11:59:38)

Неактивен

 

#15 18.11.2007 00:30:37

walrus
Участник
Откуда: Brisbane, Australia
Зарегистрирован: 18.11.2007
Сообщений: 1

Re: fail over in mysql replication

ksm написал:

Посмотрите в сторону circular replication, появившийся в 5.1. Там каждый сервер и мастер и слейв

А почему 5.1? если мне не изменяет склероз это с 5.0. Ссылку дадите где написано что с 5.1

Неактивен

 

#16 18.11.2007 12:55:10

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

Вы правы, walrus, в документации 5.0 указано, что круговая репликация поддерживается: http://dev.mysql.com/doc/refman/5.0/en/ … -increment

В дополнение, отмечу, что репликация с кластера на кластер работает корректно только в 5.1 (в 5.0 она работает, но реплиицруются только изменения, произведенные на SQL-сервере, который является мастером, тогда как в кластере апдейты могут идти на любую SQL-ноду)

Неактивен

 

#17 15.04.2008 15:20:16

dima
Участник
Зарегистрирован: 15.04.2008
Сообщений: 1

Re: fail over in mysql replication

Если взять две машины и поставить количество реплик 2
на каждой запустить ndb_mgm (там есть возможность в кластере запускать неколько )  + ndbd + sql node и в навеску heartbeat
в итоге получаем - данные одинаковы на обеих машинах
в случае падения одной из них вторая посредством heartbeat меняет свой ip и замещает выпавшую
если не прав поправьте меня

Неактивен

 

#18 15.04.2008 18:26:49

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3874

Re: fail over in mysql replication

Такое возможно только в Carrier Grade, если отключить арбитраж. Если не отключить арбитраж, то одна mgm нода будет арбитром и при ее падении, друга нода отключится. Посмотрите пожалуйста статью http://webew.ru/articles/252.webew и комменты к ней.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson