У меня есть приложение чата, в котором уже тысячи пользователей. Серверы расположены в США (штат Орегон). Пользователи распределены по всему миру. Я начал сталкиваться с проблемой, связанной с медленным ответом сервера для пользователей в Индии. Я хочу создать такую же инфраструктуру в Индии. Основная проблема - репликация MySQL. В Индии создается новый мастер MySQL, но репликация Мастер-Мастер создает проблемы, поскольку база данных содержит таблицы с идентификатором автоинкремента в качестве первичного ключа. Насколько я понимаю, следующий процесс выполняется
Предположим, что идентификатор автоинкремента теперь равен 1000, время - XXXXXXX000 мс, а задержка между регионом Орегон и Мумбаи составляет 200 мс
- В XXXXXXX000 мс, Сервер1 (США) добавляет новую строку в таблицу xyz, и теперь идентификатор автоинкремента равен 1001.
- В то же время, XXXXXXX000 мс, Сервер2 (Ind) добавляет новую строка в таблице xyz, и теперь идентификатор идентификатора автоинкремента равен 1001 для этой же таблицы.
- Через 200 мс запрос, выполненный на сервере Server1 (US), реплицируется на сервер Server2 (Ind) с идентификатором автоинкремента, равным 1001. но не удалось выполнить, потому что таблица уже имеет это значение.
- Аналогично, запрос, выполненный на сервере Server2 (Ind), реплицируется на сервер Server1 (US), у которого идентификатор автоинкремента равен 1001, но выполнить не удалось, поскольку таблица уже имеет это значение.
Одним из найденных мной решений было установить значения auto_increment_increment и auto_increment_offset на обоих хостах, как определено http://www.clusterdb.com/mysql-cluster/setting-up-mysql-asynchronous-replication-for-high-availability. Мне удалось воспроизвести это, но я не уверен, что это правильный подход для производственной установки на AWS EC2. Любые предложения будут оценены.