¿Es imprudente ejecutar la replicación en el mismo servidor físico?

Estoy contemplando configurar una replicación Maestro-Esclavo para mi base de datos. El servidor esclavo se usará para redundancia y posiblemente un servidor de informes. Sin embargo, uno de los mayores problemas con los que me encuentro es que ya estamos al máximo en nuestro centro de datos. Por lo tanto, agregar otro servidor físico no es una opción.

Nuestro servidor de base de datos existente está bastante subutilizado en cuanto a CPU (los promedios de carga nunca superan realmente 1 en un quad-core). Entonces, la idea principal es agregar algunas unidades nuevas y duplicar la memoria (de 8GB a 16) y ejecutar una segunda instancia de mysql en la misma máquina física. Cada instancia tendría discos separados para la base de datos.

¿Hay algo malo con esta idea?

Editar (más información): (afortunadamente) nunca me ha pasado algo lo suficientemente malo como para derribar el servidor, pero estoy tratando de planificar con anticipación. Por supuesto, tenemos respaldos nocturnos de los que podríamos recuperarnos. Pero pensé que tener los datos redundantes en discos separados proporcionaría una solución más rápida si fallaban las unidades del servidor maestro (obviamente no si la máquina completa se apaga).

En cuanto al aspecto de los informes, las tablas de las que informaríamos son MyIsam. Por lo tanto, realizar lecturas costosas en las mismas tablas en las que se está escribiendo puede atascar el servidor. Supuse que tener un servidor esclavo del que informar no afectaría al servidor principal siempre que le arrojáramos suficiente RAM (ya que la carga de la CPU aún no ha sido un problema).

Para obtener redundancia en términos de confiabilidad del sistema y seguridad de datos, ejecutar un esclavo en la misma máquina que el maestro no le ofrece nada (o casi). Si sucede algo lo suficientemente malo como para derribar al maestro, probablemente también derribará al esclavo.

Para usuarios puramente segregados por razones de derechos de acceso, un buen RDBMS ofrecerá formas más efectivas de hacerlo.

La ejecución de las dos bases de datos en la misma máquina requerirá más RAM para ejecutarse con la misma eficiencia, ya que las dos bases de datos competirán por espacio para mantener varios buffers y cachés. Sin embargo, puede haber un beneficio de rendimiento a través de la segregación de carga IO, si los archivos de datos para el esclavo están en unidades físicas diferentes que el maestro. En este caso, puede ejecutar informes complejos que requieren muchas lecturas de disco contra el esclavo sin competir por el maestro por el ancho de banda de E / S de la unidad.

Editar: como menciona DTest en su comentario a continuación, otro beneficio posible de un DB esclavo (incluso si está en las mismas unidades que el maestro) es que las consultas complejas de larga duración en el esclavo que de otro modo podrían causar problemas de bloqueo para el día a día Las consultas de ejecución diaria en el maestro son más seguras. Aunque todavía es mejor tener el esclavo en diferentes unidades, ya que las consultas tan importantes pueden causar problemas de contención de E / S.

No me queda claro cómo esto resuelve su problema. No hay redundancia ya que está en el mismo hardware físico, el mismo núcleo del sistema operativo, los mismos binarios de MySQL, tal vez diferentes discos pero en el mismo controlador de almacenamiento, etc. Y la razón de una base de datos de informes es descargar consultas de la base de datos OLTP y como todo está en el mismo kit, ¿de dónde viene la potencia extra? ¿O hay algo más que intenta obtener de esta configuración?

Un uso concebible para esto sería segregar a los usuarios de alguna manera, tal vez, pero de nuevo, habría pensado que podría haberse hecho GRANT.

De hecho, se considera imprudente, ¿solo estás tratando de aprovechar más núcleos? ¿Cuáles son los objetivos de la nueva consideración de diseño?

(publicado como respuesta, no como comentario para mantener el hilo de conversación centrado)

Esto puede ser una espada de doble filo

Puede ejecutar varias instancias de mysql como esclavos de solo lectura en el mismo servidor que el maestro, siempre que cada instancia de MySQL se encuentre en un disco diferente. Esto solo es deseable si está ejecutando versiones anteriores de MySQL que no aprovechan los núcleos múltiples (CPU). Las últimas versiones de MySQL pueden ajustarse para usar las CPU múltiples, lo que hace innecesario el acceso a múltiples núcleos ejecutando múltiples instancias de MySQL.

Al mismo tiempo, también es una muy mala idea. Muchos clientes míos han hecho esto para ahorrar dinero en la compra de servidores bare metal o VM. Cualquier aumento en la carga del servidor puede afectar a todas las instancias de MySQL en ejecución debido a malas consultas, consultas lentas, demasiadas conexiones, uso de memoria saturada, memoria insuficiente del servidor, almacenamiento en caché, etc. en cualquier instancia de MySQL. Esto también agrega complejidad de la aplicación al tener que acceder a las diferentes instancias de MySQL a través de su número de puerto y también estaría a merced de TCP / IP.

Cruzaría la replicación en un servidor diferente, es decir, el esclavo de A en B y el esclavo de B en A. Ejecutamos múltiples instancias en nuestros servidores y no hemos tenido problemas ya que nuestros servidores MySQL no estaban en capacidad. La conmutación por error a un servidor en ejecución es mucho más rápido que hacer una restauración desde una copia de seguridad.