Где разместить общую БД для двух географически разделенных доменов с одинаковым контентом?

А ты про законы в курсе? Чаще всего у тебя выбора нет и ты обязан хостить данные в той же стране.

Хостить базу далеко от сервера это плохая идея. Между Россией и ЮВА нет нормальных каналов. Делай свой CDN лучше. А сервер держи в одном месте.

ты обязан хостить данные в той же стране

Кто ж проверит?

А ты про законы в курсе? Чаще всего у тебя выбора нет и ты обязан хостить данные в той же стране.

Кому он чем обязан, он что юр. лицо? Да и на сколько я знаю, в РФ например требования для местного хранения относят только персональные данные пользователей. А это всякие там ip, юзер агент, регистрационные данные и анкеты.

С каких пор ip и юзерагент стали пд?

С каких пор ip и юзерагент стали пд?

Они ими всегда были. Зарегистрированное время сесси у оператора связи. Там присвоенный за это время в сети за это время ip адресс и все остальное. Это считается персональными данными.

Прочитав много материала, решил не реплицировать базу данных (в моем случае нужно было «мастер-мастер»), но вместо этого разместить БД на стороннем, третьем VPS хостинге с резервированием.

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

Ну и да, лазить в свою базу через интернет очень плохо сказывается на производительности даже если канал исправен.

Решение еще не принял, но Сингапур-Россия не лучший канал, разве что для вещания стрима в HLS с буфером до минуты. Может, рассмотреть Казахстан для БД?

Оппоненты репликации «мастер-мастер» в реальном времени говорят, что на таком расстоянии при активности юзеров может возникнуть критический сбой, и восстанавливать придется обе базы данных. Хотя речь идет о форуме, о малом видеохостинге (папки будут синхронизированы) и сайте объявлений. Т.е. не сильно критичны простои или даже потери данных.

Нет, сбора и хранения персональных данных (даже реальных имен) не планируется. Спасибо за мнение о своем CDN. Но есть теперь реальность, что в какое-то время в РФ сервер может стать временно недоступен, по крайней мере, для внешних пользователей.

А там как судья решит на основании других фактов

Да, я нагуглил решение ВС РФ от 2020 года

но Сингапур-Россия не лучший канал

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

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

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

Три движка с унифицированной регистрацией и авторизацией, восстановлением пароля (уже выполнено):

• Форум XenForo

• Видеохостинг PHP Melody

• движок сайта недвижимости Open Real Estate

Все установлено в одну БД

Кажется, что вы заранее усложняете, не зная какие дивиденды это принесет.

Точно не нужно реплицировать бд, просто стоит определиться с регионом размещения.

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

Интернет в Азии печален, а нынче с хуситами вообще труба.

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

Немного мыслей из общих соображений.

Не надо брать хостинги, где шарятся ресурсы (типа OpenVZ); те, где хостер может без предупреждений начать инженерные работы и погасить вашу машину и пр. (обычно, это встречается в тарифе «Эконом»); те, которые в каких-то сомнительных резиденциях: сам хостинг может жить, а канал по дороге к нему кто-нибудь заполнит на неопределённый срок, а вам страдать.

Не понял, почему вы рассматриваете только два варианта: «репликация есть» и «репликации нет». Можно поделить базу на ту часть, которая нужна для отображения данных, и на ту, которая модифицируется. Пусть первая будет read-only и актуализируется репликацией от мастера, но располагается рядом с (каждым) выходным узлом, а вторая — будет мастером в read-write и хостится где угодно, ну например, в России (так как оттуда 50%). Да, модифицирующие запросы будут долгими, но их же немного (или нет?). Здесь, конечно, исхожу из того, что у вас будет связность между узлами, иначе не очень понятно, как вы хотите данные, хранящиеся по одну сторону стены, иметь по другую сторону стены.

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

Но даже в случае, если вам по модели подходит только master-master, то можно и нужно переписать взаимодействие с базой на conflict-free процедуры (см. Wikipedia: Conflict-free replicated data type). Ну например, вместо возможного апдейта счётчика x := x + 1 в (потенциально всех) мастер-узлах разрешить делать в них только инсёрт в дополнительную таблицу с указанием действия inc(x), а потом уже на специально выделенном мастере — супермастере — выполнять мёрж этих отложенных действий в x := x + N с удалением обработанных.

Про статику не спрашивали, конечно, но согласен, что решение поставить кеширующий Nginx в каждой локации (a la свой CDN) хороший начальный вариант.

Вроде бы в оригинальном посте много информации, но и как будто очень мало:

1. Какая нагрузка планируется вообще? Я понял про 50%, но может, там всего ничего. Всё же вы базу на VPS планируете разместить — вряд ли речь о корпоративном хайлоаде.
2. Какие пожелания/ожидания по задержкам? Выше вот пользователь пишет, что вещают, мол, из Европы, и всех устраивает. Может, вас тоже устроит ваша текущая конфигурация? (Ну или если текущей ещё нет, то такая конфигурация, когда база хостится прямо на одном из узлов, а другой до неё ходит через весь интернет.)
3. Какого размера собственно база? Если небольшая, то надо смотреть на те хостинги, где ваша база влезет в оперативную память. Если большая, то надо ещё и место для бекапов предусмотреть, и трафик заложить входящий/исходящий.
4. Из описаний не понятно, как база используется. То ли один запрос за сессию, через который приложение выгружает профиль пользователя и дальше его препарирует. То ли по сто запросов на каждую страницу, и без проксирующих кешей тут никак.

В общем, я бы сказал, что чем проще каждое отдельное взаимодействие агентов, тем легче его сделать надёжным. Тут под агентами я понимаю и клиент–сервер, и мастер–реплика, и другие смыслы; а под простотой как чисто описательную (условно, количество слов, которыми вы сможете описать, что делает этот запрос), так и количество технологических слоёв через которые такой запрос пройдёт. Можно навертеть архитектурную архитектуру 80-го уровня, но какой-нибудь мелкий винтик у такой машины открутится, и все колёса разъедутся на раз.