Возможно, Galera не является правильным решением для очень нестабильной сети.
Если бы у каждого острова был свой собственный сервер, который был бы достаточно надежным, то половина проблемы была бы решена.Получение данных на (и от) других островов должно быть выполнено с помощью кода приложения, лежащего в основе схем.
Схема и схема потока данных должны были бы избегать различных случаев, когда могли бы быть созданы УНИКАЛЬНЫЕ (или ПЕРВИЧНЫЕ) ключиодновременно на отдельных островах.UUID - это одно из решений, но оно плохо работает для огромных баз данных.
Тогда возникает проблема «устаревших» данных.Если сервер на изолированном острове имеет «старые» данные с других островов, может ли пользователь испортить ситуацию, воздействуя на эти устаревшие данные?
Итог: либо работайте над повышением надежности сети, либо оставайтесь на месте.на вашу голову, чтобы сделать приложение надежным.
Альтернативы ...
Циркуляр с более чем 2 действительно плохо.Любое отключение оставляет остальное в нечетном состоянии - происходит репликация, а другая - нет.А если сервер действительно умирает, то это большой кошмар для ремонта.
Репликация из нескольких источников ... Учитывая, что у вас есть небольшие базы данных и доступ к острову intER только для чтения, это может быть хорошим решением,У вас есть один сервер, который является Slave для всех остальных.То есть, у каждого Острова был бы Мастер, и (когда сеть работает) копировал материал для этого общего Раба.(Есть ли вероятность того, что один остров останется подключенным?)
Все формы репликации / кластеризации возобновляют репликацию и довольно быстро «догоняют» после того, как сеть снова оживает.
Что касается UUIDsпротив AUTO_INCREMENT - если все записи в какую-либо конкретную таблицу и все связанные таблицы происходят только через сервер одного острова, тогда я не вижу необходимости в UUID.
(В любом случае, только с 100 МБ /остров, UUID, вероятно, не упадет с обрыва производительности.)