| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > Объединение БД с нескольких серверов (mysql) |
| Автор: pethead 2.7.2009, 15:18 |
| дано: несколько mysql серверов. на каждом ведется своя локальная БД. требуется: иметь на некоем отличном от этих серверов компе суммарную таблицу со всех вышеописанных компов - пока есть мысль: сбрасывать суммарную БД, коннектится по очереди к каждому и забирать все данные и просто добавлять, в итоге в конце цикла обновления имеем какое суммарное объединение всех данных. просто натолкните на мысль куда копать, каким инструментом делается и называется? это репликация? я конечно искал на предмет репликации, но сами термины не совсем понятны - то ли это что мне надо или там для другого. разумеется я сам разберусь со временем и даже сам все реализую, но ведь для того и форум чтобы общаться и помогать. я не прошу сделать работу вместо себя, я прошу пояснения в технологиях. и годится ли репликация для моей задачи? или данная задача решается правильной настройкой только механизма репликации? повсеместно говорится, репликация хороша, в тех задачах когда изменения производятся редко и на одном узле, другие же только читают. у меня же наоборот изменения на всех узлах, а читать один должен? |
| Автор: skyboy 2.7.2009, 16:15 |
| в принципе, да, репликация, как механизм, тебе и нужна. кроме того, что по описанию тебе надо репликация слиянием: merge replication. только не похоже, чтоб mysql поддерживало такой механизм. |
| Автор: DimW 2.7.2009, 16:26 |
| ради интереса порылся к доке по MySQL, что бы понять какие средства существуют для сведения данных из нескольких баз в одну, и вот что нарыл, может пригодиться: http://dev.mysql.com/doc/refman/5.0/en/federated-use.html |
| Автор: Akina 2.7.2009, 16:31 | ||
Почему? репликация в мускуле односторонняя - есть сервер, есть клиент. В данном случае центральный сервер будет клиентом репликации, а серверы с базами - серверами репликации. Другое дело если строить кластер репликации (кластер синхронизации) - там оба сервера будут и сервером, и клиентом репликации одновременно. |
| Автор: skyboy 2.7.2009, 17:24 | ||
я думал, клиент может быть настроен на репликацию только с одним сервером. и если и менять настройки/сервер - то каким-то планировщиком или ещё как. а встроенными средствами, просто конфигурацией - не получится. я не прав? Добавлено через 1 минуту и 43 секунды мне вот интересна классическая задача объединения двух источников данных в один - как быть с записями, у которых совпадают первичные/уникальные ключи, но не совпадают значения в остальных полях? или у тебя такого не может быть? Добавлено через 2 минуты и 12 секунд последний вопрос, конечно, не к Akina, а к pethead. |
| Автор: Akina 2.7.2009, 21:43 |
| Теоретически схема должна быть такая - своя БД или своя таблица для репликации с каждым сервером. В центре же реплицированные данные либо сливаются в одну базу/таблицу, либо используются данные (merge) непосредственно из реплицируемых копий. Тогда же и решается проблема конфликтов. |
| Автор: pethead 3.7.2009, 04:07 |
| нет. у меня на каждом сервере свои уникальные записи. они не могут повторяься, перескекаться с другими с других серверов, скажем так - сервера это погодные накопители данных с мест, а суммарная БД это суммарная БД с этих мест. изза перебоев связи данные с мест не могутсразу передаваться на единый один сервер, поэтому заведены локальные. я так понял что эта репликация собственно делается самой БД (на центральном сервере создается таблица с параметром CONNECTON?) если ее настроить на эту репликацию? так? т.е. писать какой то внешний скрипт\прогу для объединения данных не надо? понял так : что на центральном сервере создаются реплицированные таблицы с мест, собственно объединять их в одну уже наверное не стоит, а сразу делать выборки уже с этих таблиц - поскольку они будут являться копиями с мест? |
| Автор: Akina 3.7.2009, 08:08 |
| http://dev.mysql.com/doc/refman/6.0/en/replication.html |
| Автор: pethead 3.7.2009, 18:25 |
| спасибо |
