Percona Server with XtraDB Morgan Tocker morgan@percona.com
1
Show of Hands ★ ★ ★ ★ ★ ★ ★ ★
2
InnoDB? MyISAM? XtraDB? MySQL 4.x? MySQL 5.0.x? MySQL 5.1? MySQL 5.5? Something else?
Agenda for Today ★ ★ ★
3
1. Introduction 2. “How InnoDB Works”. 3. Percona Server with XtraDB.
Agenda for Today ★ ★ ★
4
1. Introduction 2. “How InnoDB Works”. 3. Percona Server with XtraDB.
InnoDB History ★ ★ ★ ★ ★ ★ ★ ★
5
1994 - First line of code written 1999 - InnoDB “complete”. 2001 - First alpha of working with MySQL. ... 2005 - MySQL 5.0 released with COMPACT row format. ... 2008 - InnoDB Plugin Announced 2010 - InnoDB Plugin 1.1 Announced (to ship with 5.5)
InnoDB History ★ ★ ★ ★ ★ ★ ★ ★
5
1994 - First line of code written 1999 - InnoDB “complete”. 2001 - First alpha of working with MySQL. ... 2005 - MySQL 5.0 released with COMPACT row format. Long delays while ... MySQL 5.0, 5.1 is released. 2008 - InnoDB Plugin Announced 2010 - InnoDB Plugin 1.1 Announced (to ship with 5.5)
InnoDB Limitations (as at 5.0) Slow Crash Recovery Process
Not enough diagnostic information, particularly around threads that write data/sync
Only one buffer pool. No QoS of mapping tables to buffer pool or pinning indexes/content to prevent eviction.
Poor Multi CPU Scalability
Broken group commit support
No way to see contents of buffer pool.
No way to limit the memory resident data dictionary size.
No features for warming big buffer pools on server start.
The adaptive hash does not suit all workloads.
Not able to take advantage of a No real ability to configure more powerful IO system, that tablespaces - just two limited can sustain multiple concurrent options. threads.
Page flushing is not aggressive enough, early enough leading up to checkpoints.
Insert buffer shows weakness - IO read ahead assumptions can be up to 1/2 the buffer pool have no configuration options / size - and doesn’t make active ability to disable. attempts to be more aggressive at contracting when reaching limit.
Limited number of undo segments limits concurrent transactions to 1024.
6
= Patch Available in some form.
InnoDB Limitations (as at 5.0) Can’t move tables between servers.
Slow statistics not available in slow query log.
Replication is not transactional.
No way to force checkpoint
Can’t cluster on an index other than Primary key.
Opening tables is serialized by LOCK_Open mutex.
No way to freeze checkpoint/ flushing activity.
auto_increment scalability is very bad.
No parallel query execution plans.
Adding files to a table space must be done via configuration file not online.
Statistics sampling is done by 10 random dives - limited control over resampling
Index statistics don’t persist on restart and are recalculated each time.
Can’t change page sizes without recompile. Not possible to have multiple page sizes.
Diagnostics - Can’t see a history of deadlocks.
Can’t control page fill factor.
7
= Patch Available in some form.
InnoDB Limitations (as at 5.0) InnoDB pages have checksums - a very helpful feature to detect silent corruption. The problem is there’s 2 checksums and there may be benefit from being able to change the algorithm.
Further improvements possible to IO. InnoDB’s emulated async IO may not be required. Newer system calls like fallocate/fadvise may lead to improvements.
No memory manager or effective way to limit memory use. This is both true for MySQL and the overhead consumed with InnoDB meta data.
Insert buffer does not assist for delete operations.
Dropping an index recreates the whole table.
Indexes can not be added online
InnoDB per page memory/ storage overhead could probably be reduced.
There are no features to compress/pack indexes.
There is no support for additional index algorithms (such as hash or bitmap)
8
= Patch Available in some form.
What’s the plugin? ★
★
Until recently, the InnoDB version has been tied closely to the MySQL release. MySQL 5.1’s pluggable storage engine API ✦
★
Important Note: The default InnoDB storage engine in MySQL 5.1 is not the InnoDB plugin version. ✦
9
Developers have increased freedom to make improvements independent of MySQL.
But the plugin version has been declared GA.
Enabling the InnoDB Plugin ★
MySQL considers the plugin 1.0 GA from 5.1.46. It is included, but not enabled in most downloads: ✦
★
10
[mysqld] ignore-builtin-innodb plugin-load=innodb=ha_innodb_plugin.so
See: http://dev.mysql.com/doc/refman/5.1/en/ innodb.html
The plugin also brings ★
New features! ✦
★
11
CPU scalability, fast index creation, buffer pool tablescan resistance, fast crash recovery...
It is the main focus of new InnoDB development.
Why do I tell you this long story? ★
XtraDB is a fork of the InnoDB plugin. ✦
★
“Fork” doesn’t necessarily mean the same as it used to. ✦
✦
✦
12
i.e. it inherits all [plugin] features. Think of it like after market enhancements you can make to your vehicle. Percona rebases XtraDB against new plugin releases. The on disk format in XtraDB does not change by default. i.e. You can switch InnoDB<->XtraDB all day long.
Release Model ★
★
Short release cycle. Changes are mostly incremental enhancements / minor features. Rebases against new MySQL releases. ✦
i.e. Version number should be reads as: Percona-Server-server-51-5.1.47-rel11.0.47.rhel5.x86_64.rpm Major MySQL Version XtraDB Release Version Minor MySQL Version
13
Releases History â&#x2DC;&#x2026;
14
Historical average of a new release every 1-2 months: Release-1
Dec 2008
Release-11.1
June 2010
Release-2
Dec 2008
Release-11.2
July 2010
Release-3
Feb 2009
Release-11.3
September 2010
Release-4
April 2009
Release-12**
September 2010
Release-5
April 2009
Release-11.4
September 2010
Release-6
July 2009
Release-12.1
October 2010
Release-7
August 2009
Release-11.5
October 2010
Release-8
Oct 2009
Release-11.6
November 2010
Release-9
Jan 2010
Release-12.3
December 2010
Release-9.1
March 2010
Release-11.7
December 2010
Release-10
April 2010
Release-12.4
December 2010
Release-10.1
May 2010
Release-12.5
January 2011
Release-11*
June 2010
So what changes? ★
Most of the enhancements fall into two different categories: ✦
✦
15
Performance Improvements Operational / Usability Features
Weâ&#x20AC;&#x2122;ll get to explaining these changes in just a second... (First I need to explain how InnoDB works).
Agenda for Today ★ ★ ★
17
1. Introduction 2. “How InnoDB Works”. 3. Percona Server with XtraDB.
â&#x20AC;&#x153;Numbers everyone should knowâ&#x20AC;? L1 cache reference Branch mispredict L2 cache reference Mutex lock/unlock Main memory reference Compress 1K bytes with Zippy Send 2K bytes over 1 Gbps network Read 1 MB sequentially from memory Round trip within same datacenter Disk seek Read 1 MB sequentially from disk Send packet CA->Netherlands->CA
18
0.5 ns 5 ns 7 ns 25 ns 100 ns 3,000 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 150,000,000 ns
See: http://www.linux-mag.com/cache/7589/1.html and Google http:// www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
About Disks. ★
10,000,000 ns = 10ms = 100 operations/second. ✦
★
The actual time has dramatic variation. ✦
✦
19
This is about the average for a 7200RPM drive. The variation is because disks are mechanical. We can much write faster sequentially than randomly.
[default] Everything is buffered! â&#x2DC;&#x2026;
When you write to a file, hereâ&#x20AC;&#x2122;s what happens in the Operating System: Block 9, 10, 1, 4, 200, 5.
Block 1, 4, 5, 9, 10, 200
What happens to this buffer if we loose power?
20
The OS provides a way! â&#x2DC;&#x2026;
$ man fsync Synopsis #include <unistd.h> int fsync(int fd); int fdatasync(int fd);
Hint: MyISAM just writes to the OS buffer and has no durability.
Description fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) where that file resides. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
21
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
Knowing this: ★ ★
InnoDB wants to try and reduce random IO. It can not (safely) rely on the operating system’s write buffering and be ACID compliant. ✦
22
.. and InnoDB algorithms have to compensate.
Basic Operation (High Level)
Log Files
SELECT * FROM City WHERE CountryCode=始AUS始
Buffer Pool
23
Tablespace
Basic Operation (High Level)
Log Files
SELECT * FROM City WHERE CountryCode=始AUS始
Buffer Pool
23
Tablespace
Basic Operation (High Level)
Log Files
SELECT * FROM City WHERE CountryCode=始AUS始
Buffer Pool
23
Tablespace
Basic Operation (High Level)
Log Files
SELECT * FROM City WHERE CountryCode=始AUS始
Buffer Pool
23
Tablespace
Basic Operation (High Level)
Log Files
SELECT * FROM City WHERE CountryCode=始AUS始
Buffer Pool
23
Tablespace
Basic Operation (High Level)
Log Files
SELECT * FROM City WHERE CountryCode=始AUS始
Buffer Pool
23
Tablespace
Basic Operation (cont.)
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.)
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.)
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.)
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.) 01010
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.) 01010
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.) 01010
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Basic Operation (cont.) 01010
Log Files UPDATE City SET name = 'Morgansville' WHERE name = 'Brisbane' AND CountryCode='AUS'
Buffer Pool
24
Tablespace
Why don’t we update? ★
This is an optimization! ✦
✦
★
25
The log file IO is sequential and much cheaper than live updates. The IO for the eventual updates to the tablespace can be optimized as well.
Provided that you saved enough to recover, this shouldn’t matter should it?
More on Logs... ★
Logs are only used during recovery. ✦
★
★
26
Not even read when we need to write down dirty pages!
Log Files
To figure out which pages need to be evicted we have two lists - the flush list and the LRU. Log activities are all assigned a LSN (log sequence number).
Log Files, Checkpoints, etc. ★
Most database systems work this way: ✦
★
★
27
In Oracle the transaction logs are called “Redo Logs”.
The background process of syncing dirty pages is normally referred to as a “Checkpoint”. InnoDB has fuzzy checkpointing.
Log Writing ★
You can change increase innodb_log_file_size. This will allow InnoDB to “smooth out” background IO for longer. ✦
28
Tip: Optionally you could change innodb_log_files_in_group as well. Be aware that your effective log file is innodb_log_file_size * innodb_log_files_in_group
Log Writing (cont.) ★
You can also change innodb_flush_log_at_trx_commit to 0 or 2 to reduce the durability requirements of this write. ✦
★
innodb_log_buffer_size may also help buffer changes for longer before writing to the logs. ✦
29
Requires less flushing - particularly helpful on systems without writeback caches!
Very workload dependent - tends to be more helpful for writing big TEXT/BLOB changes.
In summary ★
On commit, the log has to be flushed to guarantee changes. ✦
★ ★
★
30
Nothing else has to be done.
What visibility do we have into these operations? How do we decide how much background work to do per second? What happens if we fall behind in background work?
Agenda for Today ★ ★ ★
31
1. Introduction 2. “How InnoDB Works”. 3. Percona Server with XtraDB.
Terminology Oracle Product
License
Percona Equivalent Product
License
MySQL Server
GPL
Percona Server
GPL
The InnoDB Storage GPL Engine (Plugin edition)
The XtraDB Storage Engine
GPL
InnoDB Hot Backup
XtraBackup
GPL
Commercial
(GPL = Completely free for you to use. Support not included.)
32
Some changes come free â&#x2DC;&#x2026;
33
Some of the features from the InnoDB plugin...
Fast Index Creation ★
In built-in InnoDB, simple statements require table to be completely rebuilt: ✦
✦
✦
★
ALTER TABLE my_table ADD INDEX my_idx (col1); CREATE INDEX my_idx ON my_table (col1); ALTER TABLE my_table DROP INDEX my_idx;
In InnoDB plugin, these statements just recreate the index, provided that: ✦
✦
34
Inherited via Plugin
The index is not the primary key. The index does not use the UTF-8 character set (BUG #33650)
Fast Index Creation (cont.) ★ ★
Fast index creation only requires a READ LOCK. When the fast indexes are created, they are first presorted, and then inserted in order. ✦
35
This results in a better index fill factor, and a faster index insertion.
IO scalability ★
--innodb_io_capacity - Set the number of IO operations per second the server is capable of to influence background thread algorithms (default 200). ✦
★
36
Inherited via Plugin
100 IOPS is about the capability of a single 7200RPM disk.
--innodb_read_io_threads and -innodb_write_io_threads - Using multiple IO threads will often lead to better performance on bigger raid systems.
CPU Scalability ★
★
InnoDB doesn’t perform so well on systems with a lot of CPUs/cores. 3-4 main patches: ✦
✦
✦
✦
★
37
Inherited via Plugin
Faster locking on Linux, Windows and Solaris. Option to disable InnoDB internal memory allocator. Improvements to thread concurrency settings. Using the PAUSE instruction in InnoDB spin loops.
Most of these changes are transparent!
Whatâ&#x20AC;&#x2122;s a Mutex? Thread #1
Thread #2 Ima Server Thread #3 4 Connections
Thread #4
38
Whatâ&#x20AC;&#x2122;s a Mutex? (cont.)
Ima Server
X X
Thread #1
4-1 = 3
Thread #2
4-1 = 3
Thread #3 4 Connections
Thread #4
39
Whatâ&#x20AC;&#x2122;s a Mutex? (cont.)
Ima Server Thread #3 3 Connections
Thread #4
40
Mutexes become hotspots â&#x2DC;&#x2026;
The longer the mutex is held, the more likely you can hold up other tasks - and reduce CPU scalability:
CPUs in use 41
Adaptive Flushing â&#x2DC;&#x2026;
42
First invented in Percona Server
Handle background work more aggressively as log space runs out.
* Adaptive Checkpointing also available in Percona Server http://www.mysqlperformanceblog.com/2008/11/13/adaptive-checkpointing/
Fast Crash Recovery â&#x2DC;&#x2026;
First invented in Percona Server
Crash recovery in InnoDB can be very slow. From MySQL BUG #29847: [28 Oct 2008 21:40] James Day One reported effect of this performance limitation is that a system with 24GB buffer pool size could only recover 10% after 2 hour. With a 4G buffer pool and innodb_flush_method=O_DIRECT removed the system recovered completely in 30 minutes. Partial workarounds. 1. During recovery, temporarily reduce innodb_buffer_pool_size to force InnoDB to flush pages from the flush list. A value of 4G is likely to be reasonable. 2. During recovery, temporarily remove O_DIRECT so that the operating system can cache changes during recovery.
43
Performance Improvements Improved Buffer Pool Scalability
Separate location of double write buffer*
Improved IO Path + adaptive checkpointing
Transaction logs larger than 4G supported.
Remove excess fcntl calls
Insert buffer controls Separate purge thread Completely disable the query cache. Faster page checksums*
44
Strip comments before using query cache
Data dictionary memory consumption controls Support for different page sizes*
Improved Rollback Segment Scalability*
Increased number of undo slots* Per session configuration of innodb_flush_log_at_trx_commit
* Changes on disk format (not backwards compatible)
Improved Buffer Pool Scalability ★
Additional patches to what is already available in the InnoDB Plugin. ✦
Splits the buffer pool mutex into smaller mutexes: • • • •
45
Flush list mutex LRU mutex Free mutex hash mutex
Data Dictionary control ★
★
Once an InnoDB table is opened it is never freed from the in-memory data dictionary (which is unlimited in size). XtraDB introduces: ✦
✦
46
--innodb_dict_size_limit - a configuration item in bytes. innodb_dict_tables - a status variable for number entries in the cache.
Undo Slots ★
In the built-in InnoDB, the number of undo slots is limited to 1024. ✦
✦
★
47
This means the number of open transactions is limited to 1023. See: http://bugs.mysql.com/bug.php?id=26590 Some statements require 2 undo slots.
In XtraDB, this is expanded to 4072 with -innodb_extra_undoslots=1.
Warning: This is binary format incompatible!
Rollback Segments ★
In XtraDB, it’s also possible to have more than one rollback segment. ✦
★ ★
Each segment contains undo slots.
Configuration is --innodb-extra-rsegments=N This has the added effect of reducing mutex contention on the rollback segment: ✦
“Mutex at 0×1b3e3e78 created file trx/trx0rseg.c line 167″ http://www.percona.com/docs/wiki/perconaxtradb:patch:innodb_extra_rseg http://www.mysqlperformanceblog.com/2009/10/14/tuningfor-heavy-writing-workloads/
48
Warning: This is binary format incompatible!
Fast Checksums â&#x2DC;&#x2026;
â&#x2DC;&#x2026;
49
The InnoDB page checksum computation is slower than it needs to be. XtraDB has the option to use a faster checksum format.
Warning: This is binary format incompatible!
Different Page Sizes â&#x2DC;&#x2026;
50
XtraDB now has support for different page sizes - 4K, 8K, 16K.
Warning: This is binary format incompatible!
Separate Purge Thread â&#x2DC;&#x2026;
51
Cleans up a long history list length faster:
See: http://www.mysqlperformanceblog.com/2009/10/14/ tuning-for-heavy-writing-workloads/
Usability Enhancements Show data dictionary
Show contents of the buffer pool Save index statistics between restarts Import / export of buffer pool contents
Store buffer pool in shared memory segment
52
User / Index / Table statistics
Log connection errors Import / export of innodb_file_per_table tables
Transactional Replication
Deadlock counter Retain query response time distribution.
Disable automatic statistics regeneration
Advise in processlist when waiting on Query cache mutex.
Better handling of corrupted tables
Improved slow query log
Show Temporary Tables
Show Buffer Pool Contents mysql> SELECT d.*,round(100*cnt*16384/(data_length+index_length),2) fit FROM (SELECT schema_name,table_name,count(*) cnt,sum(dirty),sum(hashed) FROM INNODB_BUFFER_POOL_PAGES_INDEX GROUP BY schema_name,table_name ORDER BY cnt DESC LIMIT 20) d JOIN TABLES ON (TABLES.table_schema=d.schema_name AND TABLES.table_name=d.table_name); +-------------+---------------------+---------+------------+-------------+--------+ | schema_name | table_name | cnt | sum(dirty) | sum(hashed) | fit | +-------------+---------------------+---------+------------+-------------+--------+ | db | table1 | 1699133 | 13296 | 385841 | 87.49 | | db | table2 | 1173272 | 17399 | 11099 | 98.42 | | db | table3 | 916641 | 7849 | 15316 | 94.77 | | db | table4 | 86999 | 1555 | 75554 | 87.42 | | db | table5 | 32701 | 7997 | 30082 | 91.61 | | db | table6 | 31990 | 4495 | 25681 | 102.97 | | db | table7 | 1 | 0 | 0 | 100.00 | +-------------+---------------------+---------+------------+-------------+--------+ 7 rows in set (26.45 sec)
53
Source: http://www.mysqlperformanceblog.com/ 2010/03/26/tables-fit-buffer-poo/
Save Buffer Pool Contents ★
Export the contents of the buffer pool to a file called ‘ib_lru_dump’ in the data directory: ✦
★
Restored ib_lru_dump: ✦
54
SELECT * FROM information_schema.XTRADB_ADMIN_COMMAND /*! XTRA_LRU_DUMP*/; SELECT * FROM information_schema.XTRADB_ADMIN_COMMAND /*! XTRA_LRU_RESTORE*/;
Note: Not the actual contents - it takes 8 bytes to remember the address of a 16K page.
Transactional Replication â&#x2DC;&#x2026;
More resilience from slaves crashing - XtraDB no longer relies on the relay-log.info file. â&#x153;Ś
55
Instead log coordination is stored in InnoDB tables internally.
Import/Export tables ★
★
★
Because --innodb-file-per-table still has information (data dictionary, undo) in the global tablespace you can’t just back it up by itself. With a new setting, --innodb_expand_import=1, this is no longer the case. Tip: The import/export still has to be done with XtraBackup. Documentation available here: http://www.percona.com/docs/wiki/percona-xtradb:patch:innodb_expand_import
56
Better Handling of Corrupt Tables â&#x2DC;&#x2026;
57
Instead of crashing the server when a table is discovered as corrupt, just mark the table as corrupt and continue.
The Slow Query Log $ tail /var/log/mysql.slow .. MySQL Server # Time: 100924 13:58:47 # User@Host: root[root] @ localhost [] # Query_time: 399.563977 Lock_time: 0.000110 Rows_sent: 1 Rows_examined: 46313608 SET timestamp=1285336727; select STRAIGHT_JOIN count(*) as c, person_id FROM cast_info FORCE INDEX(person_id) INNER JOIN title ON (cast_info.movie_id=title.id) WHERE title.kind_id = 1 GROUP BY cast_info.person_id ORDER by c DESC LIMIT 1;
$ mysql -e “SET GLOBAL log_slow_verbosity = ‘full’;” $ tail /var/log/mysql.slow Percona Server .. # Time: 100924 13:58:47 # User@Host: root[root] @ localhost [] # Thread_id: 10 Schema: imdb Last_errno: 0 Killed: 0 # Query_time: 399.563977 Lock_time: 0.000110 Rows_sent: 1 Rows_examined: 46313608 Rows_affected: 0 Rows_read: 1 # Bytes_sent: 131 Tmp_tables: 1 Tmp_disk_tables: 1 Tmp_table_sizes: 25194923 # InnoDB_trx_id: 1403 # QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: Yes Tmp_table_on_disk: Yes # Filesort: Yes Filesort_on_disk: Yes Merge_passes: 5 # InnoDB_IO_r_ops: 1064749 InnoDB_IO_r_bytes: 17444847616 InnoDB_IO_r_wait: 26.935662 # InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000 # InnoDB_pages_distinct: 65329 SET timestamp=1285336727; select STRAIGHT_JOIN count(*) as c, person_id FROM cast_info FORCE INDEX(person_id) INNER JOIN title ON (cast_info.movie_id=title.id) WHERE title.kind_id = 1 GROUP BY cast_info.person_id ORDER by c DESC LIMIT 1;
58
User Statistics ( Not Possible )
MySQL Server
mysql> SET GLOBAL userstat_running = 1; Percona mysql> SELECT DISTINCT s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME FROM information_schema.statistics `s` LEFT JOIN information_schema.index_statistics IS ON (s.TABLE_SCHEMA = IS.TABLE_SCHEMA AND s.TABLE_NAME=IS.TABLE_NAME AND s.INDEX_NAME=IS.INDEX_NAME) WHERE IS.TABLE_SCHEMA IS NULL; +--------------+---------------------------+-----------------+ | TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | +--------------+---------------------------+-----------------+ | art100 | article100 | ext_key | | art100 | article100 | site_id | | art100 | article100 | hash | | art100 | article100 | forum_id_2 | | art100 | article100 | published | | art100 | article100 | inserted | | art100 | article100 | site_id_2 | | art100 | author100 | PRIMARY | | art100 | author100 | site_id | ... +--------------+---------------------------+-----------------+ 1150 rows IN SET (1 min 44.23 sec)
59
Server
(Related) Xtrabackup Features â&#x2DC;&#x2026; â&#x2DC;&#x2026;
60
Report on fragmentation of indexes: $ xtrabackup --stats --tables=art.link* -datadir=/mnt/data/mysql/ ... table: art/link_out104, index: PRIMARY, space id: 12, root page 3 leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91% ...
http://www.mysqlperformanceblog.com/2009/09/14/statisticsof-innodb-tables-and-indexes-available-in-xtrabackup/
The End â&#x2DC;&#x2026;
61
Questions?