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

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

Наш існуючий сервер баз даних недостатньо використовується настільки, як CPU (середнє завантаження ніколи насправді не перевищує 1 на чотирьохядерному ядрі). Отже, провідна ідея полягає в тому, щоб підкинути нові диски та подвоїти пам'ять (від 8 ГБ до 16) та запустити другий екземпляр mysql на тій же фізичній машині. Кожен екземпляр мав би окремі диски для бази даних.

Чи щось не так у цій ідеї?

Редагувати (детальніше): У мене (на щастя) ніколи не траплялось нічого поганого, щоб зняти сервер, але я намагаюся планувати заздалегідь. Ми, звичайно, маємо нічні резервні копії, від яких ми могли відновитись. Але я подумав, що надлишки даних на окремих дисках забезпечать швидше рішення, якщо диски головного сервера вийдуть з ладу (очевидно, ні, якщо вся машина вимикається).

Що стосується аспекту звітності, то будь-які таблиці, про які ми звітували б, є MyIsam. Таким чином, дорогі читання на тих самих таблицях, в які записуються, можуть забруднити сервер. Моє припущення, що підлеглий сервер для звітування про це не вплине на основний сервер, якщо ми кинули на нього достатню кількість оперативної пам’яті (оскільки завантаження процесора ще не було проблемою).

Для надмірності з точки зору надійності системи та безпеки даних, що працює підлеглим на тій же машині, що і майстер, вам нічого не пропонує (або близько). Якщо трапиться щось досить погане, щоб збити господаря, воно, ймовірно, також зведе раба.

Для чисто розділених користувачів з причин прав доступу хороша RDBMS запропонує більш ефективні способи цього зробити.

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

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

Мені не зрозуміло, як це вирішує вашу проблему. Немає надмірності, оскільки це одне і те ж фізичне обладнання, те саме ядро ​​ОС, ті ж бінарні файли MySQL, можливо, різні диски, але на тому ж контролері зберігання тощо. все на одному комплекті, звідки надходить додаткова потужність? Або є щось інше, що ви намагаєтеся отримати з цього налаштування?

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

Це справді вважається нерозумним, ти просто намагаєшся скористатися більшою кількістю ядер? Які цілі розгляду нового дизайну?

(розміщено як відповідь, а не коментар, щоб тримати розмовну нитку)

Це може бути меч з двома кінцями

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

У той же час це теж дуже погана ідея. Багато моїх клієнтів зробили це, щоб заощадити гроші на придбанні голого металу або VM-серверів. Будь-які сплески завантаження сервера можуть впливати на всі запущені екземпляри MySQL через погані запити, повільні запити, занадто багато з'єднань, використання перенасиченої пам'яті, недостатня пам'ять сервера, обробка кешу тощо, в будь-якому одному екземплярі MySQL. Це також додає складності додатку через доступ до різних екземплярів MySQL через їх номер порту, а також ви були б на користь TCP / IP.

Я б перетнув реплікацію на іншому сервері, тобто раб A на B і B slave на A. У нас запущено декілька примірників на наших серверах і не виникло проблем, оскільки наші сервери MySQL не працювали. Помилка на працюючий сервер набагато швидше, ніж відновлення з резервної копії.