репликация
- Автор темы Mongolor
- Дата начала
60? сдохнет стопудово, если обновлений много.
решается обычно пачкой промежуточных серверов с blackhole engine, с которых уже реплицируются слейвы.
-~{}~ 14.06.10 19:29:
http://jroller.com/dschneller/entry/mysql_replication_using_blackhole_engine
решается обычно пачкой промежуточных серверов с blackhole engine, с которых уже реплицируются слейвы.
-~{}~ 14.06.10 19:29:
http://jroller.com/dschneller/entry/mysql_replication_using_blackhole_engine
Mongolor
Новичок
меня больше интересует вопрос про ip шки, хотя я думаю динамик днс решит этот вопрос.
а задача: что-то вроде 60 компов в локалке таких же как сервер.
-~{}~ 15.06.10 14:33:
да, и как действует репликация если машина на которой произошли изменения в данный момент не имеет связи с сервером? она получается реплицируется по приходу сервера в онлайн? или стучиться к нему интервально, до того момента как сервер не появится?
ps просто с репликацией не приходилось еще работать
а задача: что-то вроде 60 компов в локалке таких же как сервер.
-~{}~ 15.06.10 14:33:
да, и как действует репликация если машина на которой произошли изменения в данный момент не имеет связи с сервером? она получается реплицируется по приходу сервера в онлайн? или стучиться к нему интервально, до того момента как сервер не появится?
ps просто с репликацией не приходилось еще работать
Gas
может по одной?
Причём репликация не просто master<-> 60 slaves, а судя по этой фразе:
Может вам подойдёт схема вида:
1 master, который находится в локалке, остальные компы в сети к нему конектятся, а ваш "сервер" во вне, является слейвом master'а. Итог: получаем классическую схему 1 master - 1 slave, мастер всегда доступен, slave-сервер обновляется по мере наличия инета.
А может речь вообще не про базы данных? тема хоть и в ветке про mysql, но у автора не увидел ни одного слова про mysql, базы данных, всё какие-то "компы" и "сервер".
-~{}~ 15.06.10 14:08:
Как работает репликация в mysql, можно почитать хотя бы в документации
все машины являются master'ами.
Может вам подойдёт схема вида:
1 master, который находится в локалке, остальные компы в сети к нему конектятся, а ваш "сервер" во вне, является слейвом master'а. Итог: получаем классическую схему 1 master - 1 slave, мастер всегда доступен, slave-сервер обновляется по мере наличия инета.
А может речь вообще не про базы данных? тема хоть и в ветке про mysql, но у автора не увидел ни одного слова про mysql, базы данных, всё какие-то "компы" и "сервер".
-~{}~ 15.06.10 14:08:
Как работает репликация в mysql, можно почитать хотя бы в документации
если в оффлайне (то есть обновляются непостоянно), я бы ручками "диффы" генерил. храним в каждой табличке updated timestamp, по запросу отдаем все что новее последнего обращения (удаленные придется метить флажком, да). ну и гзиповать еще это все.
репликация это же бинлоги - ~90% оверхеда получится. подразумевая почти постоянный офлайн ~= медленное/дорогое соединение, получается нехилая разница.
репликация это же бинлоги - ~90% оверхеда получится. подразумевая почти постоянный офлайн ~= медленное/дорогое соединение, получается нехилая разница.
Gas
может по одной?
Под офлайном обычно понимается отсутствие инета, но не локальной сети. Если локалка всегда доступна, то однозначно в ней нужно делать одну общую для всех клиентов базу данных, а потом её уже реплицировать во вне, чтоб количество mysql серверов было минимальным. Если клиенты должны уметь работать совсем автономно (без локалки), то здесь советы я давать не буду (ну кроме "погугли"
.
Mongolor
я бы написал синхронизацию данных на уровне приложения с учетом логики
на уровне данных неизбежны коллизии - в офлайне могут обновить данные на разных серверах, и автоматическая синхронизация или не сработает, или потеряет какие-то изменения
-~{}~ 17.06.10 12:28:
тут веб-сервис будет работать с REST/SOAP
я бы написал синхронизацию данных на уровне приложения с учетом логики
на уровне данных неизбежны коллизии - в офлайне могут обновить данные на разных серверах, и автоматическая синхронизация или не сработает, или потеряет какие-то изменения
-~{}~ 17.06.10 12:28:
тут веб-сервис будет работать с REST/SOAP
prolis
Новичок
А если делать совсем по-взрослому, в качестве промышленного решения, то такие системы состоят из:
1. Основной/резервный центр хранения данных
2. Узловые станции (опционально)
3. Клиентские станции
4. Протокол обмена обновлений
Основной центр рассылает обновления справочников бд и программных пакетов обновлений по своим подписчикам - узловым хостам. Клиентские станции при обращении к своим хостам по доступным им протоколам обмениваются обновлениями, синхронизируя свои представления локальных бд.
Ой не, я в одном посте не распишу, сколько там всего накручено внутри логики серверов, шин обмена и протоколов, нужно знать ограничания бизнес-процессов проектируемой системы.
1. Основной/резервный центр хранения данных
2. Узловые станции (опционально)
3. Клиентские станции
4. Протокол обмена обновлений
Основной центр рассылает обновления справочников бд и программных пакетов обновлений по своим подписчикам - узловым хостам. Клиентские станции при обращении к своим хостам по доступным им протоколам обмениваются обновлениями, синхронизируя свои представления локальных бд.
Ой не, я в одном посте не распишу, сколько там всего накручено внутри логики серверов, шин обмена и протоколов, нужно знать ограничания бизнес-процессов проектируемой системы.