Je rencontre un problème sérieux avec les performances de réplication MySQL 5.5 entre deux machines, principalement des tables myISAM avec une réplication basée sur des instructions. Les journaux binaires et le répertoire de données mysql sont tous deux situés sur le même Fusion ioDrive.
Le problème était un gros problème récemment lorsque nous avons dû suspendre la réplication pendant env. 3 heures. Il a fallu environ 10 heures pour rattraper son retard sans autre charge.
Comment puis-je augmenter les performances de la réplication? La machine B est essentiellement inactive (peu, IO, 2 cœurs max sur 16, beaucoup de RAM libre), car un seul thread mySQL écrivait des données. Voici quelques idées que j'ai eues:
- Basculez vers la réplication basée sur les lignes. Dans les tests, cela n'a donné qu'un gain de performances de 10 à 20%
- Mettez à niveau vers mySQL 5.6 avec une réplication multithread. Nous pourrions facilement diviser nos données en bases de données distinctes, et les tests de performance semblent indiquer que cela aiderait, mais le code ne semble pas prêt pour la production.
- Certaines variables de configuration qui aideront à accélérer la réplication
Le principal problème est que s'il faut 10h pour rattraper le retard après une pause de 3h, cela signifie que la réplication écrit 13h de données en 10h, ou est capable d'écrire à 130% de la vitesse des données entrant. Je cherche à au moins doubler les écritures sur la machine maître dans un proche avenir, donc désespérément besoin d'un moyen d'améliorer les performances de réplication.
Machine A:
- Maître
- 24 Go de RAM
- 1.2 To Fusion ioDrive2
- 2x E5620
- Interconnexion Gigabit
my.cnf:
[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp
log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306
log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql
log-slave-updates = true
# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000
# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32
user=mysql
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
Machine B:
- Esclave
- 36GB Ram
- 1.2 To Fusion ioDrive2
- 2x E5620
- Interconnexion Gigabit
my.cnf:
[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp
log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306
# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000
# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32
user=mysql
symbolic-links=0
plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql]
socket=/var/lib/mysql/mysql.sock
[client]
socket=/var/lib/mysql/mysql.sock
la source
Réponses:
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
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é.
la source
pas une réponse mais vous pourriez envisager le réplicateur de tungstène et leurs produits commerciaux pour plus de flexibilité. est-ce une utilisation à 100% du processeur sur un seul cœur qui est le goulot d'étranglement?
la source
Donc, si vous effectuez des sauvegardes sur l'esclave .. et que vous utilisez des tables de myiasme .. vous verrouillez les tables pour effectuer les sauvegardes afin d'éviter la corruption. La réplication ne peut donc pas fonctionner tant que la sauvegarde n'est pas terminée.
la source