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

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

Golova написал:

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

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

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

rgbeast написал:

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

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

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

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

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

rgbeast написал:

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

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

rgbeast написал:

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

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

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

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)

ksm написал:

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

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

ksm написал:

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

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

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