репликация

[Mongolor]

репликация

возможно ли реплицировать около 60 машин с одним сервером, если нефакт что у этих 60 машин ip адрес будет постоянным?
и вообще не тяжело будет серверу реплицироваться стаким количеством машин?

 

[fixxxer]

60? сдохнет стопудово, если обновлений много.

решается обычно пачкой промежуточных серверов с blackhole engine, с которых уже реплицируются слейвы.

-~{}~ 14.06.10 19:29:

http://jroller.com/dschneller/entry/mysql_replication_using_blackhole_engine

 

[440hz]

а можно узнать откуда такая задача?

 

[Mongolor]

меня больше интересует вопрос про ip шки, хотя я думаю динамик днс решит этот вопрос.

а задача: что-то вроде 60 компов в локалке таких же как сервер.

-~{}~ 15.06.10 14:33:

да, и как действует репликация если машина на которой произошли изменения в данный момент не имеет связи с сервером? она получается реплицируется по приходу сервера в онлайн? или стучиться к нему интервально, до того момента как сервер не появится?

ps просто с репликацией не приходилось еще работать

 

[440hz]

а задача: что-то вроде 60 компов в локалке таких же как сервер

а что? к самой базе с локалок не подключиться? я самой задачи не пойму. зачем реплицировать-то? тем более в таких масштабах.

ну выделите сервер под БД и всех туда.

 

[Gas]

Причём репликация не просто master<-> 60 slaves, а судя по этой фразе:

как действует репликация если машина на которой произошли изменения в данный момент не имеет связи с сервером

все машины являются master'ами.

Может вам подойдёт схема вида:
1 master, который находится в локалке, остальные компы в сети к нему конектятся, а ваш "сервер" во вне, является слейвом master'а. Итог: получаем классическую схему 1 master - 1 slave, мастер всегда доступен, slave-сервер обновляется по мере наличия инета.

А может речь вообще не про базы данных? тема хоть и в ветке про mysql, но у автора не увидел ни одного слова про mysql, базы данных, всё какие-то "компы" и "сервер".

-~{}~ 15.06.10 14:08:

Как работает репликация в mysql, можно почитать хотя бы в документации

 

[Mongolor]

смысл репликации в том чтобы клиентские машины могли работать в оффлайне

-~{}~ 17.06.10 01:01:

если есть какой-то другой способ работы в оффлайне я выслушаю все предложения

 

[fixxxer]

если в оффлайне (то есть обновляются непостоянно), я бы ручками "диффы" генерил. храним в каждой табличке updated timestamp, по запросу отдаем все что новее последнего обращения (удаленные придется метить флажком, да). ну и гзиповать еще это все.

репликация это же бинлоги - ~90% оверхеда получится. подразумевая почти постоянный офлайн ~= медленное/дорогое соединение, получается нехилая разница.

 

[Gas]

смысл репликации в том чтобы клиентские машины могли работать в оффлайне

Под офлайном обычно понимается отсутствие инета, но не локальной сети. Если локалка всегда доступна, то однозначно в ней нужно делать одну общую для всех клиентов базу данных, а потом её уже реплицировать во вне, чтоб количество mysql серверов было минимальным. Если клиенты должны уметь работать совсем автономно (без локалки), то здесь советы я давать не буду (ну кроме "погугли" .

 

[Mongolor]

Автор оригинала: fixxxer я бы ручками "диффы" генерил. храним в каждой табличке updated timestamp, по запросу отдаем все что новее последнего обращения (удаленные придется метить флажком, да). ну и гзиповать еще это все.

принцип понятен. можно более разжеванно?

 

[440hz]

можно более разжеванно?

тогда нужна структура БД.

 

[grigori]

Mongolor
я бы написал синхронизацию данных на уровне приложения с учетом логики

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

-~{}~ 17.06.10 12:28:

тут веб-сервис будет работать с REST/SOAP

 

[prolis]

А если делать совсем по-взрослому, в качестве промышленного решения, то такие системы состоят из:
1. Основной/резервный центр хранения данных
2. Узловые станции (опционально)
3. Клиентские станции
4. Протокол обмена обновлений
Основной центр рассылает обновления справочников бд и программных пакетов обновлений по своим подписчикам - узловым хостам. Клиентские станции при обращении к своим хостам по доступным им протоколам обмениваются обновлениями, синхронизируя свои представления локальных бд.

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

 

[440hz]

prolis

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

 

[Mongolor]

Автор оригинала: fixxxer
репликация это же бинлоги - ~90% оверхеда получится.

а в каком месте будет этот оверхед, ведь всёравно какой-то лог будет вести необходимо.