397 liens privés
Benchmark qui compare Amazon Aurora et du Percona installé sur des instances EC2 avec des différents types de stockages (general purpose ssd, provisionned iops ssd 2000/3000).
hum mais pourquoi on utilise pas ça au boulot... quand un serveur (sous percona 5.6) reboot tout seul pendant la nuit (d'ailleurs merci aws ec2 pour cette super nuit #sysadminlife)).
Actuellement il se produit exactement ceci quand le slave crash entre le commit de transaction et la mise à jour du relay-log.info:
"""
The relay-log.info file contains the position of the slave relay log, which the slave is applying. Somehow, if a crash occurs on the slave between transaction commit and update of relay-log.info, the replication can be inconsistent – indicating that the relay-log.info file may not be in sync on the disk and contains old information. As a result, when the slave starts again it will read old events from the relay log. And because of this the transaction can be applied multiple times.
"""
"""
pt-table-checksum and pt-table-sync are the finest tools from Percona Toolkit to validate data between master/slave(s). With the help of these tools you can easily identify data drifts and fix them
"""
Encore des supers outils de l'excellente suite "Percona Toolkit".
Voir aussi pt-archiver https://jeekajoo.eu/links/?KaxoGw + xtrabackup https://jeekajoo.eu/links/?zi8wkw
Mysql 5.6 apporte la réplication multi-threadée. Je vois 2 avantages parmi d'autres:
- meilleures performances parce que forcément on a un nombre de worker threads supérieur à 1
- mise en place de la réplication plus facile, moins sujette à des erreurs coté ops grâce aux GTID. En effet il n'y a plus besoin d'indiquer de MASTER_LOG_FILE / MASTER_LOG_POS. Mysql s'autopositionne en scannant les transactions dans les binlogs. Il se place sur la transaction qui n'a pas encore été exécutée sur le réplica.
Références:
Ernie Souhrada, DBA chez Pinterest, explique comment il a drastiquement amélioré les perfs mysql sans changer de hardware.
"""
When we enable all of the optimizations, we find we can achieve roughly 500 percent more read and write throughput at both 16 and 32 threads while simultaneously reducing p99 latency by over 500ms in both directions. On the read side, we go from approximately 4100 – 4600 QPS to just over 22000 – 25000, depending on concurrency. On the write side, we go from approximately 1000 QPS to 5100 – 6000 QPS. These are massive gains in headroom and performance achieved with just a few simple changes.
"""
sur du i2.4xlarge (de la grosse instance ec2 de porc), percona-server-5.6, ubuntu 12.04.
Voir aussi http://www.slideshare.net/denshikarasu/all-your-iops-are-belong-to-us-a-pinteresting-case-study-in-mysql-performance-optimization
qui va plus dans les détails, avec les tests sysbench pour les différents disques, versions de kernel, modifs my.cnf, irqbalance, options de montage, etc... qui ont permi de tirer les conclusions.
On apprend notamment que le kernel en version 3.18 montre de meilleurs perfs IO qu'en 3.13.
Très pointu.
"""
STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
"""
Une procédure pour réduire le fichier 'ibdata1' qui a fini par prendre 190G+ sur un de nos serveurs, alors que nous avons paramétré un innodb_file_per_table à 1.
La faute à des OPTIMIZE TABLE qui avaient été faits justement dans le but de reprendre l'espace disque censé être gagné suite à des DELETE.
"""
Unfortunately, OPTIMIZE TABLE against an InnoDB table stored in ibdata1 does two things:
- Makes the table's data and indexes contiguous inside ibdata1
- It makes ibdata1 grow because the contiguous data is appended to ibdata1
"""
coude
toujours pratique.
bien penser à l'option --single-transaction tout de même sur une base utilisée par une appli.
https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html#option_mysqldump_single-transaction
"""
Now you can resize InnoDB buffer pool online. Since MySQL 5.7 innodb_buffer_pool_size is a dynamic variable which provides the ability to resize buffer pool without restarting MySQL server.
"""
yaisse! #sysadmin
Un outil pour supprimer ou archiver des grosses quantité de données dans une base de donnée mysql (ou fork, comme percona server, mariadb..), sans trop impacter les perfs.
Exemple de commande:
pt-archiver --source h=localhost,D=base,t=table --purge --where 'truc < DATE(DATE_SUB(NOW(), INTERVAL 365 DAY))' --statistics --limit 200 --commit-each --why-quit --progress 100000
Dans cet exemple, je supprime les lignes de la table 'table' par paquets de 200, avec une clause 'where'.
J'affiche des stats toutes les 100000 lignes supprimées. --purge supprime les données.
Autres options qui me semblent utiles:
--check-slave-lag: Mettre en pause l'archivage si le lag du slave dépasse --max-lag
--dry-run: Pour juste afficher les requêtes qui vont être jouer sans rien exécuter. Particulièrement utile pour faire un plan d'exécution (EXPLAIN) dessus et voir l'impact éventuel sur les perfs.
--no-ascend: Ne pas se fier à l'index. Cela peut être une bonne stratégie s'il n'y a pas de trous dans les données à supprimer.
Cet outil très pratique fait partie de la suite percona-toolkit: http://www.percona.com/doc/percona-toolkit/2.2/
Ancêtre: http://www.maatkit.org/
encore un article pertinent du blog de percona (qui est pour moi une référence dès qu'on veut gérer un mysql en prod)
celui-ci traite des problèmes de réplication. la cause, la résolution.
complémentaire avec https://jeekajoo.eu/links/?OXR4gQ
create table foobar ( id int(4) auto_increment not null primary key, name varchar(15));
insert into users foobar (0,"foo"),(0,"bar");
un ptit pdf qui apprend à résoudre des problèmes de réplication mysql classiques.
one more bug
