Est-il imprudent d'exécuter la réplication sur le même serveur physique?

J'envisage de configurer une réplication maître-esclave pour ma base de données. Le serveur esclave sera utilisé pour la redondance et éventuellement un serveur de rapports. Cependant, l'un des plus gros problèmes que je rencontre est que nous sommes déjà au maximum de l'alimentation dans notre centre de données. L'ajout d'un autre serveur physique n'est donc pas une option.

Notre serveur de base de données existant est assez sous-utilisé en ce qui concerne le processeur (les moyennes de charge ne dépassent jamais vraiment 1 sur un quad-core). L'idée principale est donc de lancer de nouveaux disques et de doubler la mémoire (de 8 Go à 16) et d'exécuter une deuxième instance mysql sur la même machine physique. Chaque instance aurait des disques distincts pour la base de données.

Y a-t-il quelque chose qui cloche avec cette idée?

Edit (plus d'informations): Je n'ai (heureusement) jamais rien fait de mal pour arrêter le serveur, mais j'essaie de planifier à l'avance. Nous avons bien sûr des sauvegardes nocturnes que nous pourrions récupérer. Mais je pensais que disposer des données redondantes sur des disques séparés fournirait une solution plus rapide si les disques du serveur maître tombaient en panne (évidemment pas si la machine entière s'éteint).

En ce qui concerne l'aspect du rapport, tous les tableaux dont nous ferions rapport sont MyIsam. Ainsi, des lectures coûteuses sur les mêmes tables que celles sur lesquelles l'écriture est en cours peuvent endommager le serveur. Mon hypothèse était qu'un serveur esclave à signaler n'affecterait pas le serveur principal tant que nous y allions suffisamment de RAM (car la charge du processeur n'a pas encore été un problème).

Pour la redondance en termes de fiabilité du système et de sécurité des données, exécuter un esclave sur la même machine que le maître ne vous offre rien (ou à proximité). Si quelque chose d'assez mauvais pour faire tomber le maître se produit, il fera probablement tomber l'esclave aussi.

Pour des utilisateurs purement séparés pour des raisons de droits d'accès, un bon SGBDR offrira des moyens plus efficaces de le faire.

L'exécution des deux bases de données sur la même machine nécessitera plus de RAM pour fonctionner avec la même efficacité car les deux bases de données seront en concurrence pour l'espace pour conserver leurs différents tampons et caches. Cependant, il peut y avoir un avantage en termes de performances via la séparation de charge IO, si les fichiers de données de l'esclave se trouvent sur des lecteurs physiques différents de ceux du maître. Dans ce cas, vous pouvez exécuter des rapports complexes nécessitant de nombreuses lectures de disque sur l'esclave sans rivaliser avec le maître pour la bande passante d'E / S du lecteur.

Edit: comme DTest le mentionne dans son commentaire ci-dessous, un autre avantage possible d'une base de données esclave (même si sur les mêmes lecteurs que le maître) est que les requêtes complexes de longue durée dans l'esclave qui pourraient autrement causer des problèmes de verrouillage pour la journée. les requêtes exécutées quotidiennement sur le maître sont plus sûres. Bien qu'il soit préférable de disposer de l'esclave sur différents lecteurs, ces requêtes importantes sont susceptibles de provoquer des problèmes de contention d'E / S.

Je ne vois pas comment cela résout votre problème. Il n'y a pas de redondance car il est sur le même matériel physique, le même noyau de système d'exploitation, les mêmes binaires MySQL, peut-être des disques différents mais sur le même contrôleur de stockage, etc. tout est dans le même kit, d'où vient la puissance supplémentaire? Ou y a-t-il autre chose que vous essayez d'obtenir de cette configuration?

Une utilisation envisageable pour cela serait de séparer les utilisateurs d'une manière ou d'une autre, mais encore une fois, j'aurais pensé que cela aurait pu être fait GRANT.

C'est en effet considéré comme imprudent, essayez-vous simplement de profiter de plus de cœurs? Quels sont les objectifs de la nouvelle considération de conception?

(publié en tant que réponse et non en tant que commentaire pour garder le fil de conversation concentré)

Cela peut être une épée à double tranchant

Vous pouvez exécuter plusieurs instances de mysql en tant qu'esclaves en lecture seule sur le même serveur que le maître, à condition que chaque instance de MySQL réside sur un disque différent. Cela n'est souhaitable que si vous exécutez des versions plus anciennes de MySQL qui ne tirent pas parti de plusieurs cœurs (CPU). Les dernières versions de MySQL peuvent être réglées pour utiliser réellement les processeurs multiples, ce qui rend inutile l'accès à plusieurs cœurs en exécutant plusieurs instances de MySQL.

En même temps, c'est aussi une très mauvaise idée. Beaucoup de mes clients l'ont fait pour économiser de l'argent sur l'achat de serveurs virtuels ou de serveurs virtuels. Tous les pics de charge du serveur peuvent affecter toutes les instances MySQL en cours d'exécution en raison de requêtes incorrectes, de requêtes lentes, d'un trop grand nombre de connexions, d'une utilisation réduite de la mémoire, d'une mémoire insuffisante du serveur, d'un écrasement du cache, etc., dans n'importe quelle instance MySQL. Cela ajoute également de la complexité à l'application en ayant à accéder aux différentes instances de MySQL via leur numéro de port et vous serez également à la merci de TCP / IP.

Je sillonnerais la réplication sur un serveur différent, c'est-à-dire l'esclave A sur B et l'esclave B sur A. Nous exécutons plusieurs instances sur nos serveurs et n'avons eu aucun problème car nos serveurs MySQL n'étaient pas à pleine capacité. Le basculement vers un serveur en cours d'exécution est beaucoup plus rapide que d'effectuer une restauration à partir d'une sauvegarde.