Replicate Master DB для разных подчиненных

Question

У меня есть базовая база данных, которая будет облачным сервером, состоящим из разных школ.

Тип приборной панели, в котором указаны детали каждой школы. Может редактировать свою информацию и другие данные.

Теперь эти школы развернуты в соответствующем школьном месте, которое будет локальным сервером.

Тип панели мониторинга, который может редактировать только определенную школу, развернутую на локальном сервере. Может редактировать свою информацию и другие данные.

Теперь я хочу, чтобы синхронизировать cloud to local server в соответствующей школе, если что-то изменилось. Это также относится к local to cloud server.

Примечание: Если вы, ребята, когда-нибудь пробовали Evernote, который может редактировать информацию заметки на любом устройстве вы используете и все еще быть в состоянии синхронизировать, когда у вас есть интернет или вручную щелкнул Синхронизировать.

Когда локальный сервер не имеет подключения к Интернету и редактировал некоторые данные в школе. После того, как Интернет встанет, данные с локального и облачного серверов должны быть синхронизированы.

Это логика, которую я преследую.

бы кто-нибудь пролить некоторый свет для меня, где начать? Я не мог придумать никакого решения, которое бы соответствовало моей проблеме.

Я также думаю об использовании php для цикла foreach по всей таблице и данных, соответствующих текущей дате и времени. Но я знаю, что это будет так плохо.

Отредактировано: Я удалил ссылки на другие вопросы по этому вопросу.

Применение колышки, которые я нашел в

• Evernote
• Todoist

Серверы:

• Локальный компьютер сервера: Windows 10 (Развернутые в школах)
• Облако сервер: Вероятно, некоторые выделенный сервер, который использует phpmyadmin

Не быть придирчивым, но, мы надеемся, что ответ будет вы говорите новичку освоить рабскому процесс базы данных. У меня нет опыта для этого.

Answer 1

Когда мы использовали, чтобы сделать это, мы бы:

1. Убедитесь, что все таблицы мы хотели синхронизировать имели даты-времени столбцы для создания; Модифицированный; & Удалено. Они также имели бы булевский столбец isDeleted (вместо того, чтобы физически удалять записи, мы будем указывать его на true и игнорировать его в запросах). Это означает, что мы можем запросить любые записи, которые были удалены с определенного времени, и вернуть массив этих удаленных идентификаторов.
2. В каждой БД (мастер и ведомый) создается таблица, в которой хранится последнее успешное время и время синхронизации. В мастер-таблице эта таблица хранит несколько записей: 1 для каждой школы, но в подчиненном ей просто нужна 1 запись - в последний раз, когда она синхронизируется с мастером.

В вашем случае каждый так часто каждый из рабов будет:

1. Вызов веб-сервиса (URL-адрес) мастера, позволяет сказать, что называется "helloMaster. Он будет проходить в имени школы (или в каком-то конкретном идентификаторе), в последний раз, когда они успешно синхронизируются с мастером, сведения об аутентификации (для обеспечения безопасности) и ожидают ответа от мастера о том, имел ли мастер какие-либо обновления для школы с того времени и времени предоставлена. На самом деле точка здесь просто ищет подтверждение того, что мастер доступен и прослушивается (т. Е. Интернет все еще работает).

2. Затем подчиненный вызовет другой веб-сервис, который называется «sendUpdates». Он снова перейдет в название школы, последнюю успешную синхронизацию (плюс данные проверки подлинности) & три массива для любых добавленных, обновленных и удаленных записей с момента последней синхронизации. Мастер просто подтверждает получение. Если квитанция была подтверждена, то ведомый должен перейти к шагу 3, иначе ведомое устройство снова попытается выполнить шаг 1 после паузы некоторой продолжительности. Итак, теперь у Учителя есть обновления от подчиненного. Примечание. Решайте, как объединить любые записи, если есть конфликты с его ожидающими ведомыми обновлениями.

3. После этого slave-сервер вызывает веб-сервис, который позволяет использовать 'getUpdates'. Он передает имя школы, последнюю успешную синхронизацию, данные проверки подлинности безопасности, & мастер, а затем возвращает к нему три массива для любых добавленных, обновленных и удаленных записей, которые он должен использовать для подчиненного устройства в своей базе данных.

4. Наконец, как только подчиненный пытается обновить свои записи, он затем уведомит мастера об успехе/провале через другой веб-сервис, скажем, «updateStatus». В случае успеха мастер вернет новую дату синхронизации для хранения ведомого устройства (это будет точно соответствовать дате, которую мастер хранит в своей таблице). Если это не удается, ошибка регистрируется в главном устройстве, и мы возвращаемся к шагу 1 после паузы.

Я опустил некоторые детали из об обработке ошибок, получая времена точных на все устройства (могут быть различными временными зонами привлеченных), а также некоторые другие битами и кусками, но это суть его.

Я могу сделать уточнения, подумав над ним (или другие могут отредактировать мой пост).

Надеюсь, что поможет хотя бы.

Answer 2

Я предлагаю вам идти с тривиальное решение, которое по моему мнению является:

1. Создать SQLlite или любую базу данных (MySQL или ваш выбор) в локальном сервере
2. Держите всегда работает нить который будет выполнять ping (делает вызов API) вашей основной базой данных каждые 5 минут (зависит от того, сколько задержки принято)
3. С помощью этой темы вы можете определить, подключены ли вы к Интернету или нет.

4. При подключении к Интернету

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

   b) Получите обновленные изменения с сервера после вызова API, эти изменения будут выполнены после разрешения конфликтов (например, если данные на школьном сервере были обновлены раньше, чем данные, обновленные в основной базе данных, так что вы согласитесь на основе вашего требования).

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

---

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

---

Лучше решение будет использовать Google Firebase, которая является реальной базой данных времени, который асинхронно обновляется всякий раз, когда есть изменение в любой машине, но может стоить вам больше, если его действительно не требуется. Но да, это действительно даст вам функции редактирования в реальном времени типа Evernote для ваших систем баз данных.

Answer 3

Редактировать:

Оригинальная версия этого ответа предлагается MongoDB; но с дальнейшим чтением MongoDB не так надежен с изворотливыми интернет-соединениями. К сожалению, CouchDB предназначен для автономных документов, что вам и нужно, хотя, к сожалению, сложнее получить гонг, чем MongoDB.

---

Оригинал:

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

Будучи любителем власти MySQL, мне сложно предложить вам использовать что-то еще, но в этом случае вам действительно нужно.

Вот почему -

Проблемы при использовании репликации MySQL

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

• Столкновение «Уникальный ключ» даст вам массивную головную боль; наиболее вероятной причиной этого являются идентификаторы «Auto Incrementing», которые являются общими для приложений MySQL (не используйте их для синхронизации, если там - это четкое отношение «читать + писать» -> «только для чтения», которое в вашем случае нет .)
• Первичные ключи должны быть сгенерированы каждым сервером, но уникальны для всех серверов.Возможно, добавив сочетание идентификатора сервера и уникального идентификатора для этого сервера (Server1_1, Server1_2, Server1_3 и т. Д. Не будут сталкиваться с Server2_1)
• Синхронизация MySQL поддерживает только на ходу, если вы не посмотрите на их решения для кластеризации (https://www.mysql.com/products/cluster/).

Проблемы с этим «вручную» со временем, запечатывающим запись.

В другом ответе рекомендуется хранить записи «Обновлено по времени». В то время как я сделал этот подход, есть некоторые большие проблемы, чтобы быть осторожными.

• «Unique Key» столкновения (как упоминалось выше; одни и те же проблемы - не использовать их, кроме первичных ключей, а также генерировать первичные ключи, уникальные для сервера)
• Несколько обновлений на нескольких серверах должны быть точно время -synced и столкновения обрабатываются в соответствии с правилами. Это может быть головная боль.
• Что происходит, когда обновления получаются не по порядку; какие поля были обновлены, а какие нет? Вам, вероятно, не нужно обновлять всю запись, но как вы знаете?
• Если необходимо, попробуйте один из коммерческих решений, как указано в ответах https://serverfault.com/questions/58829/how-to-keep-multiple-read-write-db-servers-in-sync и https://community.spiceworks.com/topic/352125-how-to-synchronize-multiple-mysql-servers и Strategy on synchronizing database from multiple locations to a central database and vice versa (и т.д. - Google больше)

Проблемы делать это «вручную» с журналирования.

Journalling ведет отдельную запись о том, что изменилось и когда. «База данных X, таблица Y, поле Z было обновлено до значения A в момент времени B» или «В таблице A была добавлена ​​новая запись с этими данными [...]». Это позволяет вам намного лучше контролировать, что обновлять.

• Если вы посмотрите на методы синхронизации базы данных, это на самом деле то, что происходит в фоновом режиме; в случае MySQL он хранит двоичный журнал обновлений.
• вы когда-либо делили журнал, а не оригинальную запись.
• Когда другой сервер получает запись журнала, если имеет гораздо больший обзор того, что произошло до/после, и может воспроизводить обновления и гарантировать, что вы получите правильные данные.
• проблемы возникают, когда журнал/база данных выходит из Sync (MySQL на самом деле является болью, когда это происходит!). Вам нужно иметь сценарий «обновления», готовый к показу, который находится за пределами журнала, который будет синхронизировать БД с мастером.
• Это сложно. Так ...

Решение: Использование магазина документов, предназначенного для репликации, например. MongoDB

Принимая во внимание все это, почему бы не использовать хранилище документов, которое уже делает все, что для вас? CouchDB поддерживает и обрабатывает все журналы и синхронизацию (http://docs.couchdb.org/en/master/replication/protocol.html).

Есть и другие, но я считаю, что в итоге вы получите меньше головных болей и ошибок, чем с другими решениями.

Answer 4

Это не проблема, которая может быть решена путем репликации базы данных.

Вообще говоря, репликация базы данных может работать в одном из двух режимов:

• Master/Slave репликации, который является тем, что использует MySQL. В этом режиме все записи должны быть перенаправлены на один «главный» сервер, и все базы данных реплик получают поток изменений от ведущего.

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

• Репликация на основе кворума, которая используется некоторыми более новыми базами данных. Все реплики базы данных соединяются друг с другом. Пока подключена по меньшей мере половина всех реплик (т. Е. Кластер достиг «кворума»), записи могут быть сделаны в любую из активных баз данных и будут распространены на все остальные базы данных. База данных, которая не подключена, будет обновляться, когда она присоединяется к кворуму.

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

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

Answer 5

Мастер для репликации в MySQL может быть выполнен без серьезных нарушений при использовании auto_increment. Вот ссылка, которая объясняет, как это сделать.

Если у вас есть таблицы без первичных ключей я не уверен, что будет (я всегда включаю auto_increment первичных ключи таблиц)

http://brendanschwartz.com/post/12702901390/mysql-master-master-replication

автоинкрементируемого смещение и автоинкрементный инкремент эффект значения AUTO_INCREMENT, как показано в образцах конфигурации из статьи ...

server_id   = 1 
log_bin    = /var/log/mysql/mysql-bin.log 
log_bin_index  = /var/log/mysql/mysql-bin.log.index 
relay_log   = /var/log/mysql/mysql-relay-bin 
relay_log_index  = /var/log/mysql/mysql-relay-bin.index 
expire_logs_days = 10 
max_binlog_size  = 100M 
log_slave_updates = 1 
auto-increment-increment = 2 
auto-increment-offset = 1 

server_id   = 2 
log_bin    = /var/log/mysql/mysql-bin.log 
log_bin_index  = /var/log/mysql/mysql-bin.log.index 
relay_log   = /var/log/mysql/mysql-relay-bin 
relay_log_index  = /var/log/mysql/mysql-relay-bin.index 
expire_logs_days = 10 
max_binlog_size  = 100M 
log_slave_updates = 1 
auto-increment-increment = 2 
auto-increment-offset = 2