Wow, vous avez du matériel extrêmement costaud pour ce problème. Il n'y a pas grand-chose d'autre à faire sur le plan matériel, à l'exception de la mise à niveau vers peut-être des processeurs Sandy / Ivy Bridge pour des performances 20 à 50% supérieures aux recherches Btree, etc.
Veuillez noter que mon fort est Innodb, donc je vais
- Ignorez que vous êtes myisam et agissez comme si cela ne ferait aucune différence.
- Supposons que ce problème soit suffisamment dynamique pour vous permettre de mettre à niveau. Oui, c'est une mise à niveau.
Innodb peut aider à tirer le meilleur parti de toute cette mémoire en stockant ces lignes fréquemment consultées dans son pool de mémoire tampon. Vous pouvez le régler pour qu'il soit aussi volumineux que vous le souhaitez (disons 80% de la mémoire) et les nouvelles lectures / écritures restent en mémoire jusqu'à ce qu'il ait besoin de les pousser sur le disque pour faire plus de place pour les dernières données consultées. En mémoire est un ordre de grandeur plus rapide que vos FusionIO.
Il existe de nombreuses autres fonctionnalités Innodb, telles que les hachages adaptatifs, les mécanismes de verrouillage à entrée automatique, etc. qui peuvent être une aubaine pour votre environnement. Vous connaissez cependant mieux vos données que moi.
Dans le monde innodb, une bonne solution à court terme consiste à optimiser votre esclave - avez-vous vraiment besoin de tous les index de votre esclave que vous avez sur votre maître? Les index sont une boule et une chaîne sur les insertions / mises à jour / suppressions, MÊME avec les cartes Fusion IO. Les IOPS ne sont pas tout ici. Les processeurs Sandy / Ivy Bridge ont un débit de mémoire et des performances informatiques bien meilleurs - ils peuvent faire une énorme différence par rapport aux Westmeres que vous avez maintenant. (Figure 20-50% dans l'ensemble). Supprimez tous les index dont vous n'avez pas besoin sur l'esclave!
Deuxièmement, et s'applique presque certainement à innodb uniquement, est que mk-prefetch peut savoir quelles mises à jour et avant que l'esclave les écrit. Cela permet à mk-prefetch d'exécuter une requête de lecture en premier, forçant ainsi les données à être en mémoire au moment où la seule réponse exécute la requête d'écriture. Cela signifie que les données sont en mémoire et non en fusionIO, un gain de performance rapide d'ordre de grandeur. Cela fait une énorme différence, plus que ce à quoi on pourrait s'attendre. Beaucoup d'entreprises utilisent cela comme une solution permanente. Pour en savoir plus, consultez la boîte à outils Percona .
Troisièmement, et plus important encore, une fois que vous êtes passé à Innodb, passez à la caisse de Tokutek. Ces gars ont des trucs incroyablement impressionnants qui dépassent de loin les performances d'écriture / mise à jour / suppression d'Innodb. Ils vantent l'amélioration de la vitesse de réplication comme l'un des principaux avantages, et vous pouvez voir dans leurs références pourquoi Fusions IOPS fou ne vous aidera toujours pas dans le cas de Btrees . (Remarque: non vérifié indépendamment par moi.) Ils utilisent un remplacement direct d'un index btree qui, bien que hideusement plus complexe, améliore de nombreuses limitations de vitesse algorithmique des index btree.
Je suis en train d'envisager une adoption de Tokutek. S'ils libèrent autant de vitesse d'écriture, cela me permet d'ajouter plus d'index. Puisqu'ils compressent les données et les index à des rapports aussi merveilleux (25x ils citent), vous ne payez même pas un prix (performance, maintenance) pour une augmentation des données. Vous payez cependant ($) pour leur moteur, 2500 $ / an par Go pré-compressé, IIRC. Ils ont des remises si vous faites répliquer les données, mais vous pouvez même simplement installer Tokutek sur votre esclave et garder votre maître tel quel. Consultez les détails techniques dans la conférence MIT Algoritms Open Courseware . Alternativement, ils ont des tonnes de trucs techniques sur leur blog et des livres blancs réguliers pour ceux qui n'ont pas 1:20 pour regarder la vidéo. Je crois que cette vidéo donne également la formule Big-O pour la vitesse de lecture. J'aisupposer que les lectures sont plus lentes (il y a toujours un compromis!), mais la formule est trop complexe pour que je puisse mesurer combien. Ils prétendent que c'est à peu près la même chose, mais je préfère comprendre les mathématiques (peu probable!). Vous pouvez être dans une meilleure situation pour découvrir cela que moi.
Ps Je ne suis pas affilié à Tokutek, je n'ai jamais exécuté leur produit et ils ne savent même pas que je les regarde.
Mise à jour :
Je vois que vous avez d'autres questions sur cette page et j'ai pensé que je pourrais y participer:
Premièrement, la prélecture des esclaves ne fonctionnera presque certainement pas pour myisam, sauf si vous disposez d'un environnement exceptionnel. Cela est principalement dû au fait que la prélecture verrouillera les tables sur lesquelles vous avez l'intention d'écrire, ou que le thread esclave a verrouillé la table dont le démon de prélecture a besoin. Si vos tables sont extrêmement bien équilibrées pour la réplication et que différentes tables sont écrites de manière circulaire, cela peut fonctionner - mais gardez à l'esprit que c'est très théorique. Le livre "High Performance Mysql" contient plus d'informations dans la section "Problèmes de réplication".
Deuxièmement, votre esclave suppose probablement une charge de 1,0 à 1,5, elle peut être plus élevée si vous avez d'autres procs ou requêtes en cours d'exécution mais une ligne de base de 1,0. Cela signifie que vous êtes probablement lié au processeur, ce qui est probablement le cas avec votre FusionIO à bord. Comme je l'ai mentionné plus tôt, Sandy / Ivy Bridge va donner un peu plus de punch, mais probablement pas assez pour vous aider à traverser les moments difficiles avec un minimum de retard. Si la charge de cet esclave est principalement en écriture seule (c'est-à-dire peu de lectures), votre processeur passe presque certainement son temps à calculer les positions pour les insertions / suppressions de btree. Cela devrait renforcer mon point ci-dessus sur la suppression des index non critiques - vous pouvez toujours les rajouter plus tard. La désactivation de l'hyperthreading ne fonctionnera pas, plus de CPU n'est pas votre ennemi. Une fois que vous avez dépassé 32 Go de RAM, disons 64 Go, vous devez vous soucier de la distribution de RAM, mais même alors, les symptômes sont différents.
Enfin, et surtout (ne sautez pas cette partie;)), je suppose que vous exécutez maintenant RBR (réplication basée sur les lignes) parce que vous avez mentionné une augmentation non négligeable des performances lors du changement. Cependant, il peut y avoir un moyen d'obtenir encore plus de performances ici. Le bogue 53375 de Mysql peut se manifester si vous avez des tables en cours de réplication sans clé primaire. L'esclave n'est pas assez intelligent pour utiliser autre chose qu'une clé primaire, donc l'absence de celle-ci oblige le thread de réplication à effectuer une analyse complète de la table pour chaque mise à jour. Un correctif consiste simplement à ajouter une clé primaire de substitution automatique bénigne. Je ne ferais cela que si la table était grande (disons plusieurs dizaines de milliers de lignes ou plus). Cela, bien sûr, se fait au détriment d'un autre index sur la table, ce qui fait augmenter le prix que vous payez en CPU. Notez qu'il y a très peu d'arguments théoriques contre cela, car InnoDB en ajoute un dans les coulisses si vous ne le faites pas. Le fantôme, cependant, n'est pas une défense utile contre 53375. Le tungstène peut également surmonter ce problème, mais vous devez être sûr lors de l'utilisation de tungstène que vous avez votre encodage droit. La dernière fois que j'ai joué avec, il mourrait horriblement quand toute chaîne non UTF8 devait être répliquée. C'est à peu près le moment où j'ai abandonné.
