Комментарии 8
В моём случае структура базы данных как на промежуточных серверах, так и на центральном сервере абсолютно идентична, а значит у меня есть проблема — уникальность ключевых полей.
Проблему уникальности autoincrement идентификаторов можно решить настройкой сервера:
auto_increment_increment — с каким шагом прирастают идентификаторы, одинаковое значение на всех серверах, >= количеству серверов
auto_increment_offset — смещение внутри диапазона auto_increment_increment, уникальное для каждого сервера.
А не сталкивались с проблемой, когда надо прочитать только что сохранённые данные? Например данные могут записаться на мастере не не успевают попасть на slave, тогда в ответе от сервера будут не все данные, которые только что ввели.
Все запросы типа SELECT пользователи отправляют на центральный, физически удалённый Slave-сервер. В случае если соединения с центральным сервером нет, то запросы SELECT направляются на офисный промежуточный Master-сервер.
одному мне кажется, что тут что-то не так? Если актуальные данные есть локально ('запросы SELECT направляются на офисный промежуточный Master-сервер"), то зачем обращаться к центральному узлу?
А почему просто не заюзать Percona XtraDB Cluster?
Запись призводится только тогда, когда большинство серверов с ней согласится, т.е. происходит синхронное согласование. Если происходит сплит, то запись согласуется решением большинства, т.е. надо чтобы было большинство в одном из регионов, иначе будет доступ только на чтение. Далее, при восстановлении соединения, надо учитывать что понадобится некоторое время чтобы нагнать репликацию и там, в зависимости от дельты, будет либо простая репликация, либо стягивание полностью снапшота переключением донора только на чтение. Как-то так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Multi-source репликация в MySQL5.7