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

13

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).

Derek Downey
la source

Réponses:

11

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.

David Spillett
la source
1
ma pensée était que l'esclave ne rivaliserait pas avec les verrous de table sur myIsam lors de l'écriture du maître (pour les rapports complexes).
Derek Downey
@DTest: ce serait certainement un bonus possible, oui (+1). Pour les autres types de table également lorsqu'un gros verrou (comme un verrou de table) peut être demandé par une requête de rapport complexe. J'ajouterai une note à ma réponse afin qu'il soit moins probable que l'affichage du formulaire soit coupé si d'autres commentaires apparaissent.
David Spillett
7

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.

Gaius
la source
ajouté quelques notes supplémentaires à ma question. la ségrégation des utilisateurs n'est pas ce que j'essaie d'accomplir, cependant
Derek Downey
2

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é)

jcolebrand
la source
offrent une légère protection contre les pannes de disque, et fournissent en même temps un serveur pour les rapports complexes qui ne ralentiront pas les sites de production accédant au maître.
Derek Downey
Utiliseront-ils le même contrôleur de disque ou pourrez-vous installer un nouveau contrôleur de disque en plus de nouvelles broches?
jcolebrand
1
Je viens de tomber sur celui-ci. J'ai remarqué vos questions rhétoriques mentionnant tirer parti de plusieurs cœurs. En fait, j'en ai discuté dans ma réponse deux mois après que vous ayez dit cela. +1 pour votre perspicacité devant la mienne. BTW Voici une belle vidéo sur l'exécution de MySQL plusieurs fois: youtu.be/5uKBg9prA1A
RolandoMySQLDBA
BTW Mon employeur a un client pour qui j'ai organisé cette architecture. Il a trois esclaves de lecture sur une machine (tous dans MyISAM) tandis que le maître est tout InnoDB.
RolandoMySQLDBA
1

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.

RolandoMySQLDBA
la source
0

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.

sabika
la source