percona toolkit
============
-> pt-query-digest :: Analyses a slow query log and prints a report.
* pt-query-digest --limit /u99/mysql-slow.log
(--limit: Default value 95%:20, means 'displays the 95% worst queries or top 20 worst whichever comes first)
(--interval=0.01)
-> pt-archiver :: archiving/purging
* archiving - Archiving means moving data from one table to another table
* purging - Purging means removing data
* purge :: pt-archiver -u -p -P -D -h --where 'emp_id>1000' --limit 100 --commit-each --purge
* archive :: pt-archiver -u -p -P -D -T -h --dest -h -D -T --where 'emp_id>1000' --limit 100 --commit-each
* Use --dry-run :: to know what the tool will do
-> pt-table-checksum :: Replication doesn't check data consistency. On slaves, it tries to run queries registered in the binlogs of the master.
* What can go wrong : Writing on slave, instead of master.
: Skipping replication events.
: Undeterministic writes
: Replication may stop with problems, or may continue with problems
* Computing a checksum of rows on the master and slave.
-> pt-table-sync - Will generate the queries to fix errors
* Use: --no-check-triggers option
-> pt-online-schema-change :: Problem with ALTER TABLE - It creates a copy of the table. Original table is locked during the process.
* It track changes to the original table - by using triggers
* And then copies rows in chunks, like ALTER TABLE, but without lock
* If you already have triggers, it won't work. MySQL allows only 1 trigger for each action
* Slower than plain ALTER TABLE.
* Check: --dry-run. And if all goes good replace --dry-run with --execute
============
-> pt-query-digest :: Analyses a slow query log and prints a report.
* pt-query-digest --limit /u99/mysql-slow.log
(--limit: Default value 95%:20, means 'displays the 95% worst queries or top 20 worst whichever comes first)
(--interval=0.01)
-> pt-archiver :: archiving/purging
* archiving - Archiving means moving data from one table to another table
* purging - Purging means removing data
* purge :: pt-archiver -u -p -P -D -h --where 'emp_id>1000' --limit 100 --commit-each --purge
* archive :: pt-archiver -u -p -P -D -T -h --dest -h -D -T --where 'emp_id>1000' --limit 100 --commit-each
* Use --dry-run :: to know what the tool will do
-> pt-table-checksum :: Replication doesn't check data consistency. On slaves, it tries to run queries registered in the binlogs of the master.
* What can go wrong : Writing on slave, instead of master.
: Skipping replication events.
: Undeterministic writes
: Replication may stop with problems, or may continue with problems
* Computing a checksum of rows on the master and slave.
-> pt-table-sync - Will generate the queries to fix errors
* Use: --no-check-triggers option
-> pt-online-schema-change :: Problem with ALTER TABLE - It creates a copy of the table. Original table is locked during the process.
* It track changes to the original table - by using triggers
* And then copies rows in chunks, like ALTER TABLE, but without lock
* If you already have triggers, it won't work. MySQL allows only 1 trigger for each action
* Slower than plain ALTER TABLE.
* Check: --dry-run. And if all goes good replace --dry-run with --execute
No comments:
Post a Comment