4. MariaDB Timeline
● MariaDB 5.1, GA February 2010
Table elimination, new storage engines, code
cleanup, better tests, pool of threads
5. MariaDB Timeline
● MariaDB 5.1, GA February 2010
● MariaDB 5.2, GA November 2010
Table elimination, new storage engines, code
cleanup, better tests, pool of threads
Virtual columns, extended user statistics,
segmented MyISAM keycache
6. MariaDB Timeline
● MariaDB 5.1, GA February 2010
● MariaDB 5.2, GA November 2010
● MariaDB 5.3, GA February 2012
Table elimination, new storage engines, code
cleanup, better tests, pool of threads
Virtual columns, extended user statistics,
segmented MyISAM keycache
Biggest changes to optimizer (faster
subqueries, joins, etc.), microsecond precision,
faster HANDLER, dynamic columns, better
replication (group commit, etc.), HandlerSocket
7. MariaDB Timeline
● MariaDB 5.1, GA February 2010
● MariaDB 5.2, GA November 2010
● MariaDB 5.3, GA February 2012
● MariaDB 5.5, GA April 2012
Table elimination, new storage engines, code
cleanup, better tests, pool of threads
Virtual columns, extended user statistics,
segmented MyISAM keycache
Biggest changes to optimizer (faster
subqueries, joins, etc.), microsecond precision,
faster HANDLER, dynamic columns, better
replication (group commit, etc.), HandlerSocket
More efficient threadpool, non-blocking
client library, new LIMIT ROWS
EXAMINED option, extended keys for
XtraDB/InnoDB, new SphinxSE,
dynamic replication settings, lots of
security fixes, new status variables, etc.
8. MariaDB Timeline
● MariaDB 5.1, GA February 2010
● MariaDB 5.2, GA November 2010
● MariaDB 5.3, GA February 2012
● MariaDB 5.5, GA April 2012
● MariaDB Galera Cluster, GA March 2013
Table elimination, new storage engines, code
cleanup, better tests, pool of threads
Virtual columns, extended user statistics,
segmented MyISAM keycache
Biggest changes to optimizer (faster
subqueries, joins, etc.), microsecond precision,
faster HANDLER, dynamic columns, better
replication (group commit, etc.), HandlerSocket
More efficient threadpool, non-blocking
client library, new LIMIT ROWS
EXAMINED option, extended keys for
XtraDB/InnoDB, new SphinxSE,
dynamic replication settings, lots of
security fixes, new status variables, etc.
Galera Synchronous Replication
9. MariaDB Timeline
● MariaDB 5.1, GA February 2010
● MariaDB 5.2, GA November 2010
● MariaDB 5.3, GA February 2012
● MariaDB 5.5, GA April 2012
● MariaDB Galera Cluster, GA March 2013
● MariaDB 10.0.10 (March 2014)
Table elimination, ew storage engines, code
cleanup, better tests, pool of threads
Virtual columns, extended user statistics,
segmented MyISAM keycache
Biggest changes to optimizer (faster
subqueries, joins, etc.), microsecond precision,
faster HANDLER, dynamic columns, better
replication (group commit, etc.), HandlerSocket
More efficient threadpool, non-blocking
client library, new LIMIT ROWS
EXAMINED option, extended keys for
XtraDB/InnoDB, new SphinxSE,
dynamic replication settings, lots of
security fixes, new status variables, etc.
Galera Synchronous Replication
10. MariaDB Timeline
● MariaDB 5.1, GA February 2010
● MariaDB 5.2, GA November 2010
● MariaDB 5.3, GA February 2012
● MariaDB 5.5, GA April 2012
● MariaDB Galera Cluster, GA March 2013
● MariaDB 10.0.10 (March 2014)
● MariaDB Galera Cluster 10, July 2014
Table elimination, ew storage engines, code
cleanup, better tests, pool of threads
Virtual columns, extended user statistics,
segmented MyISAM keycache
Biggest changes to optimizer (faster
subqueries, joins, etc.), microsecond precision,
faster HANDLER, dynamic columns, better
replication (group commit, etc.), HandlerSocket
More efficient threadpool, non-blocking
client library, new LIMIT ROWS
EXAMINED option, extended keys for
XtraDB/InnoDB, new SphinxSE,
dynamic replication settings, lots of
security fixes, new status variables, etc.
Galera Synchronous Replication
12. Community Contributions
MariaDB 10.0 major contributions:
● Per thread memory counting and
usage
● Base code and idea by Lixun
Peng, Taobao
● Multi-source replication
● Base code by Lixun Peng, Taobao
● GET_LOCK
● Code by Konstantin "Kostja"
Osipov, mail.ru
● CONNECT storage engine
● Code by Olivier Bertrand
https://mariadb.com/kb/en/log-of-mariadb-contributions/
● Spider storage engine
metadata_lock_info Information
schema
● Code by Kentoku Shiba, Spiral Arm
● Roles
● Code by Vicentiu Ciorbaru, Google
Summer of Code 2013
● PCRE Regular Expressions
● Code by Sudheera Palihakkara,
Google Summer of Code 2013
● Global Transaction IDs
● Some patches by Pavel Ivanov,
Google
13. MariaDB 10 in a nutshell
● MariaDB 5.5 features +
● MySQL 5.6 backported features - InnoDB/XtraDB,
PERFORMANCE_SCHEMA, online ALTER TABLE etc.
● Multi-source replication
● Global Transaction ID
● Parallel Slave Thread
● TokuDB, Spider, Connect, Cassandra storage engines
● SSD and Flash storage enhancements
● User roles
● More administration and instrumentation commands...
14. Optimizer Improvements
● Of 29 distinct enhancements noted, 28 are in
MariaDB 10. Just 1 only in MySQL 5.6.
● Enhancements include:
● Disk access optimizations.
● JOIN optimizations.
● Subquery optimizations.
● Optimized derived tables and views.
● Execution control.
● Optimizer control.
● EXPLAIN improvements.
15. Fusion-IO page compression
● Atomic writes gives a
performance increase of about
30%. By enabling fast checksum
for XtraDB it’s 50%
● By using page compression the
compression ratio is leading to
better performance and there
are less writes to disk.
● Multi-threaded flush provides
better throughput and
decreases operation latencies
delivering a performance boost
https://blog.mariadb.org/significant-performance-boost-with-new-mariadb-page-compression-on-fusionio
16. Group Commit
● binlog_commits
● Total number of
transactions committed to
the binary log
● binlog_group_commits
Total number of groups of
transactions committed to
the binary log
When sync_binlog=1 it is the
number of fsync()’s
18. Parallel Slave Thread Replication
● Sponsored by Google
● Transactions are applied in parallel if they have been executed in parallel on the
master.
● It works beyond the boundaries of MySQL 5.6 parallel slave
● Parallel threads apply to:
● Queries that are run on the master in one group commit.
● Queries that are from different domains.
● Queries from different masters
(when using multi-source
replication).
● slave_parallel_threads
● Number of parallel threads on
the slave node
● slave_parallel_max_queued
● Memory used to read ahead
in relay log
19. Multi-source Replication
● Data partitioned over many
masters can be pulled
together onto one slave for
analytical queries
● Many masters can replicate to
the same slave and a complete
backup can be done on the slave
● Newer hardware usually provides more
performance. Usually all hardware isn’t upgraded at
once and multi-source can be used for replicating
many masters to a powerful new slave.
● Up to 64 masters