Путаница при проектировании топологии базы данных

Question

Справочная информация

Я управляю (читай: унаследовано) сетью, которая очень похожа на провайдера виртуального хостинга.В инфраструктуре работает от 300 до 400 сайтов.За прошедшие годы топология базы данных стала чрезвычайно фрагментированной, так как это соотношение 1: 1 из базы данных webserver-> database.

Проблемы

• Приложения в 9 раз из 10 разработаны сторонними дизайнерскими фирмами, которые внедрили WordPress / Joomla / Drupal и т. Д.
• Базы данных случайно разбросаны по 6 серверам баз данных.Они нигде не реплицируются.
• В приложениях отсутствует концепция отдельных дескрипторов базы данных для разделения INSERT на ведущее устройство и SELECT на ведомое устройство.
• Использование встроенной репликации master в MySQL создает узкое место.,Количество вставок будет очень быстро снижать уровень мастер-базы.

Вопрос

У меня возникает вопрос, как сделать топологию базы данных максимально плоской, оставляя место для будущей масштабируемости?

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

В прошлом я изучал репликацию с несколькими мастерами, но видел много проблем с такими вещами, как коллизии столбцов auto_increment.

Я открыт для корпоративных решений.Нечто похожее на продукт Shareplex для репликации Oracle.

Каким бы ни было решение, не стоит ожидать изменения приложений в соответствии с этим новым дизайном.Поэтому такие вещи, как столбцы auto_increment, должны оставаться неизменными и распределяться по всему кластеру.

Цель

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

Это также дало бы мне отказоустойчивость, которой у меня сейчас нет.В настоящее время удаление базы данных из ротации невозможно.

Приложения, такие как Cassandra и Hadoop, выглядят удивительно похоже на то, чего я хочу достичь, но NoSQL не подходит для этих приложений.

Любые советы / указатели / учебные пособия / документация / рекомендации по продукту с благодарностью.Спасибо.

Answer 1

В прошлом я изучал мультимастерную репликацию, но видел много проблем с такими вещами, как коллизии столбцов auto_increment.

Мы используем multi-master в производстве на работе. Загадка auto-inc была исправлена ​​недавно с auto_increment_increment и auto_increment_offset, что позволяет каждому серверу иметь свой собственный шаблон идентификаторов приращений. Пока приложение не спроектировано вслепую, предполагая , что все идентификаторы будут последовательными, оно должно работать нормально.

Реальная проблема с multi-master состоит в том, что MySQL все еще иногда портит двоичный журнал. В основном это проблема ненадежных соединений, поэтому проблем не будет, если все экземпляры будут локальными.

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

Если вам нужно географическое разнообразие, мультимастер может работать.

Также обратите внимание на DRBD систему репликации на уровне дисков, которая теперь встроена в современные ядра Linux. Ранее он использовался другими для репликации MySQL и PostgreSQL, хотя у меня нет личного опыта работы с ним.

По вашему вопросу я не могу сказать, ищете ли вы высокую доступность или просто ищете (ручной или автоматический) отработка отказа. Если вы просто нуждаетесь в восстановлении после сбоя и можете иметь некоторое время простоя, тогда вам может подойти традиционная репликация master / slave. Беда в том, чтобы превратить раба, который стал хозяином, обратно в раба.