Разумно ли запускать репликацию на одном физическом сервере?

Я обдумываю настройку репликации Master-Slave для моей базы данных. Подчиненный сервер будет использоваться для резервирования и, возможно, для сервера отчетов. Тем не менее, одна из самых больших проблем, с которыми я сталкиваюсь, заключается в том, что мы уже исчерпали возможности в нашем центре обработки данных. Поэтому добавить другой физический сервер не вариант.

Наш существующий сервер баз данных недостаточно загружен по сравнению с процессором (средние нагрузки никогда не превышают 1 на четырехъядерном процессоре). Поэтому основная идея заключается в том, чтобы добавить несколько новых дисков, удвоить объем памяти (с 8 ГБ до 16) и запустить второй экземпляр mysql на той же физической машине. Каждый экземпляр будет иметь отдельные диски для базы данных.

Что-то не так с этой идеей?

Изменить (подробнее): У меня (к счастью) никогда не было ничего плохого, что могло бы сломать сервер, но я стараюсь планировать заранее. У нас, конечно, есть ночные резервные копии, которые мы могли бы восстановить. Но я полагал, что наличие избыточных данных на отдельных дисках обеспечит более быстрое решение, если диски главного сервера выйдут из строя (очевидно, нет, если вся машина выйдет из строя).

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

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

Для чисто отдельных пользователей по причинам прав доступа хорошая СУБД предложит более эффективные способы сделать это.

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

Редактировать: как DTest упоминает в своем комментарии ниже, еще одно возможное преимущество подчиненной БД (даже если на тех же дисках, что и ведущее устройство) заключается в том, что сложные длительные запросы в ведомом устройстве могут в противном случае вызвать проблемы с блокировкой для повседневной работы. Ежедневные запросы на мастере безопаснее. Хотя вам все равно лучше иметь подчиненное устройство на разных дисках, поскольку такие важные запросы могут вызвать проблемы с конфликтами ввода-вывода.

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

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

Это действительно считается неразумным, вы просто пытаетесь использовать больше ядер? Каковы цели рассмотрения нового дизайна?

(публикуется как ответ, а не как комментарий, чтобы сфокусировать разговорную ветку)

Это может быть обоюдоострый меч

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

В то же время это тоже очень плохая идея. Многие мои клиенты сделали это, чтобы сэкономить деньги на покупке голого металла или серверов виртуальных машин. Любые скачки нагрузки на сервер могут повлиять на все запущенные экземпляры MySQL из-за неправильных запросов, медленных запросов, слишком большого количества соединений, переполненного использования памяти, недостаточной памяти сервера, перебора кэша и т. Д. В любом отдельном экземпляре MySQL. Это также увеличивает сложность приложения, так как ему приходится обращаться к различным экземплярам MySQL через их номер порта, а также вы будете зависеть от TCP / IP.

Я хотел бы пересечь репликацию на другом сервере, то есть ведомом A на B и ведомом B на A. Мы запускаем несколько экземпляров на наших серверах, и у нас не было проблем, поскольку наши серверы MySQL не работали. Аварийное переключение на работающий сервер происходит гораздо быстрее, чем восстановление из резервной копии.