дано: несколько mysql серверов. на каждом ведется своя локальная БД.
требуется: иметь на некоем отличном от этих серверов компе суммарную таблицу со всех вышеописанных компов - пока есть мысль: сбрасывать суммарную БД, коннектится по очереди к каждому и забирать все данные и просто добавлять, в итоге в конце цикла обновления имеем какое суммарное объединение всех данных.

просто натолкните на мысль куда копать, каким инструментом делается и называется? это репликация?

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

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

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

в принципе, да, репликация, как механизм, тебе и нужна.
кроме того, что по описанию тебе надо репликация слиянием: merge replication. только не похоже, чтоб mysql поддерживало такой механизм.

ради интереса порылся к доке по MySQL, что бы понять какие средства существуют для сведения данных из нескольких баз в одну, и вот что нарыл, может пригодиться: http://dev.mysql.com/doc/refman/5.0/en/federated-use.html 

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

я думал, клиент может быть настроен на репликацию только с одним сервером.
и если и менять настройки/сервер - то каким-то планировщиком или ещё как. а встроенными средствами, просто конфигурацией - не получится.
я не прав?

Добавлено через 1 минуту и 43 секунды
мне вот интересна классическая задача объединения двух источников данных в один - как быть с записями, у которых совпадают первичные/уникальные ключи, но не совпадают значения в остальных полях? или у тебя такого не может быть?

Добавлено через 2 минуты и 12 секунд
последний вопрос, конечно, не к Akina, а к pethead.

Теоретически схема должна быть такая - своя БД или своя таблица для репликации с каждым сервером. В центре же реплицированные данные либо сливаются в одну базу/таблицу, либо используются данные (merge) непосредственно из реплицируемых копий. Тогда же и решается проблема конфликтов.

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

я так понял что эта репликация собственно делается самой БД (на центральном сервере создается таблица с параметром CONNECTON?) если ее настроить на эту репликацию? так? т.е. писать какой то внешний скрипт\прогу для объединения данных не надо?

понял так : что на центральном сервере создаются реплицированные таблицы с мест, собственно объединять их в одну уже наверное не стоит, а сразу делать выборки уже с этих таблиц - поскольку они будут являться копиями с мест?

Это сообщение отредактировал(а) pethead - 3.7.2009, 04:16

http://dev.mysql.com/doc/refman/6.0/en/replication.html

спасибо