Мы стремимся масштабировать нашу существующую архитектуру базы данных и нуждаемся в советах, в каком направлении двигаться.
В настоящее время у нас есть 2 веб-сервера за балансировщиком нагрузки, которые читают и записывают в одну главную базу данных, которая реплицируется на подчиненное устройство.
В идеале я бы хотел, чтобы каждый из веб-серверов указывал на свою собственную главную БД и синхронизировал данные между двумя, но, судя по тому, что я читал, использование любого типа мастер-мастер или кольцевой репликации не рекомендуется.
Я ищу общий ответ типа «что делают другие» - поставщик базы данных сейчас не вызывает беспокойства, но мы хотели бы остаться с MySQL или перейти на MSSQL.
Любые идеи будут с благодарностью приняты.
Большое спасибо,
Андрей
Следующим шагом перед сегментированием или любыми другими сложными изменениями структуры базы данных является создание 1 главного сервера для записи, но использование нескольких реплицированных серверов для чтения. Это предполагает, что ваш веб-сайт / приложение следует типичной схеме, когда гораздо больше операций чтения, чем записи.
Кроме того, вы можете подумать о настройке кластера, однако этот уровень часто пропускают, поскольку он сложен и дорог, а также хуже масштабируется, чем новые методы масштабирования.
Вы могли бы рассмотреть шардинг ваши наборы данных на нескольких серверах или используйте репликацию главный-подчиненный и выполняйте все ваши чтения против подчиненного (-ых).
Вы должны учитывать свои текущие рабочие нагрузки, данные и то, можете ли вы просто получить желаемый прирост производительности за счет обновления оборудования.