percona server compiles in innodb plugin, so you get the new version automatically

xtradb is a fork of innodb plugin
  * on disk format same (by default!) -- can switch between plugin and xtradb all day long
    * with certain options, you can change it
  * xtradb is based off of innodb plugin releases
  * more like after market enhancement

xtradb additional features
  * performance improvements
  * operation / usability features

innodb built around idea that disks are slow
  * sequential io faster than random
  * lots of variation in disk io
  * by default, everything is buffered (to get better sequential I/O)
    * this is bad if lose power
  * innodb algorithms try to compensate
    * writes changes to log file (sequential) & buffer pool, eventually checkpoints to main innodb data file
    * this is an optimization, and is where crash recovery comes from. only read from logs for startup
    * this is "transaction log"
    * background process of syncing dirty pages is a checkpoint (in innodb, this can be fuzzy)

fast index creation
  * just adds index, doesn't rebuild whole table
  * drop index is the same
  * doesn't work for utf-8, doesn't work for primary key indexes
  * requires a read lock

I/O scalability
  * can set # of operations per second per server, to influence algorithms (background work)
  * can get sudden dips in performance, if background work falls behind

CPU scalaility
  * 3 to 4 main patches
  * faster locking
  * pause instruction in spin loops
  * disable internal memory allocator
  * most changes are transparent

adaptive checkpointing - get more consistent performance, keeps background task from falling behind
  * maybe a little less peak performance

innodb plugin has much faster crash recovery
  * little more reliable, much faster
 
xtradb performance changes
  * break buffer pool lock into finer grained mutexes
  * if you have a lot of tables, enhancements to data dictionary
  * additional undo slots, with option. does change file format
  * other way to fix is with multiple rollback segments, fixes some mutex contention issues with heavy-write workloads (fixed in v5.5)
  * fast checksums (binary incompatible), needed for faster io
  * different page sizes (binary incompatible), 16k is default, can do smaller
  * separate purge thread, helps with background falling behind

xtradb usability changes (best features)
  * can show buffer pool contents, examine memory fit, can compare servers
  * can save contents of buffer pool, saves addresses of what's loaded (not the data)
    * can then restore buffer pool contents, so can restore buffer pool after restart
    * in latest v5.1 percona server, have background thread can do this
    * newer branch sorts before loads, which gets more sequential I/O
  * transactional replication, if slaves crash, slave isn't crash safe, relay-log.info isn't a safe write
    * log coordinates stored in innodb table, which is safe
  * even with file per table, there is some central data stored in ibdata1 file
    * with new setting, this is no longer the case
    * import/export still has to be done with xtra backup
    * any mysql server for export, percona server for import
  * better handling of corrupt tables (probably some hardware issue, or a bug)
    * doesn't crash innodb
    * table marked as corrupt
  * slow query log is way more verbose
    * can really tell why queries are slow
    * mk-query-digest understands these extra bits of data
  * user statistics, few tables in information schema
    * can find out indexes that are no longer used, as workload changes over time
  * some features were added to xtrabackup instead
    * fragmentation on a table
    * can decide if an index is fragmented, smarter than blind optimize table
    * this is slow, which is why xtrabackup is used instead

In clustered environment, NDB is way to go, good for write heavy, primary key heavy workloads
Percona team learns of security issues when the public does, so will lag those patches
maatkit scripts can mirror queries from one server to another, to warm up buffer pool
can compile swap out of linux kernel, fixes issue with it burning cpu when no swap file, and adjust oom thing

how can i tell if background work is falling behind? do a "show innodb status"
  * 3 numbers about log
  * if difference between last 2 numbers is large, it's how much background work to be done
  * if it is large % of log file size, then that indicates lagging