Planet MySQL - http://www.planetmysql.org/
MariaDB 10.0.10 uploaded to Debian experimental
If you’re watching the NEW queue, you’ll notice that MariaDB 10.0.10 has been uploaded targeting Debian/experimental. Package description, and to think the bug was only opened on April 2nd – pretty quick turnaround.
MariaDB in Debian unstable
Debian releases Lenny, MySQL 5.1 soon
MariaDB in Gentoo; updates for Solaris/Debian SPARC
Really large NLP corpora
Jeeze people. You’re all noisy. I’m sure it was all done for posterity’s sake.
FYI: Galera is just a provider
No news in telling Galera is the synchronous multi master solution for MySQL.
But Galera is just a provider.
What do you mean by provider?
Remember configuring “Galera”?
There are two options
wsrep_provider and wsrep_provider_options
These define the provider (Galera) and the options for the provider.
The rest of the wsrep_ options are for wsrep.
wsrep API defines a set of application callbacks and replication library calls necessary to implement synchronous writeset replication of transactional databases and similar applications. It aims to abstract and isolate replication implementation from application details. Although the main target of this interface is a certification-based multi-master replication, it is equally suitable for both asynchronous and synchronous master/slave replication.
So yes, other providers than galera are possible \o/
I.e. an asynchronous replication provider could already benefit from the parallel applying provided by wsrep :)
Concurrent, read-only, not cached: MongoDB, TokuMX, MySQL
I repeated the tests described here using a database larger than RAM. The test database has 8 collections/tables with 400M documents/rows per table. I previously reported results for this workload using a server with 24 CPU cores and a slightly different flash storage device. This time I provide a graph and use a server with more CPU cores. The goal for this test is to determine whether the DBMS can use the capacity of a high-performance storage device, the impact from different filesystem readahead settings for MongoDB and TokuMX and the impact from different read page sizes for TokuMX and InnoDB. It will take two blog posts to share everything. I think I will have much better QPS for MongoDB and TokuMX in my next post so I won't list any conclusions here.SetupI used my forked Java and C sysbench clients. The test query fetches one document/row by PK. The test database has 8 collections/tables with 400M rows per collection/table. All are in one database. I still need to enhance the Java sysbench client to support a database per collection. I tested the configurations listed below. I don't think these are the best configurations for TokuMX and MongoDB and am running more tests to confirm. The test server has 144G RAM, 40 CPU cores and a fast flash storage device.fb56.handler - 740G database, MySQL 5.6.12 with the Facebook patch, InnoDB, page_size=8k, data fetched via HANDLERfb56.sql - 740G database, MySQL 5.6.12 with the Facebook path, InnoDB, page_size=8k, data fetched via SELECTorig57.handler - 740G database, official MySQL 5.7.4, InnoDB, page_size=8k, data fetched via HANDLER. orig57.sql - 740G database, official MySQL 5.7.4, InnoDB, page_size=8k, data fetched via SELECTtokumx32 - 554G database, TokuMX 1.4.1, quicklz, readPageSize=32K, 16K filesystem readaheadtokumx64 - 582G database, TokuMX 1.4.1, quicklz, readPageSize=64K, 32K filesystem readaheadmongo24 - 834G database, MongoDB 2.4.9, powerOf2Sizes=0, 16K filesystem readaheadmongo26 - 874G database, MongoDB 2.6.0, powerOf2Sizes=1, 16K filesystem readaheadResultsResults for MySQL 5.7.4 are not in the graph to keep it readable and are similar to MySQL 5.6.12. Note that MySQL is able to get more than 100,000 QPS at high concurrency, TokuMX reaches 30,000 and MongoDB isn't able to reach 20,000. I think MongoDB and TokuMX can do a lot better when I reduce the filesystem readahead for both and reduce the read page size for TokuMX and results for that are in my next post. MongoDB also suffers in this test because the PK index is so large that all leaf nodes cannot fit in RAM so there is more than one disk read per query. This isn't something that goes away via tuning. The workaround it to make sure the database:RAM ratio isn't too big (and spend more money on hardware).This lists the QPS from the graph.point queries per second 8 16 32 40 clients 39928 63542 102294 107769 fb56.handler 33630 56834 91132 102336 fb56.sql 39714 63359 101987 106205 orig57.handler 33561 56725 90900 101476 orig57.sql 12586 22738 31407 32167 tokumx32 10119 16373 18310 18232 tokumx64 12782 16639 17350 17435 mongo24 12503 17474 17988 18022 mongo26AnalysisThese tables list the average disk read rate from iostat r/s and the average number of disk reads per query. InnoDB is by far the most efficient with the smallest number of disk reads per query. TokuMX benefits from having the smallest database courtesy of quicklz compression but might suffer from a larger read page size (32k and 64k). But I don't think that is the only reason why the disk reads per query ratio is so much larger than InnoDB and TokuMX. I am repeating tests with an 8k read page size to confirm. MongoDB suffers from a PK index that is too large to be cached so disk reads are done for it and the document store. Both TokuMX and MongoDB might also do extra reads because of the filesystem readahead and I am repeating tests with smaller values for it to confirm.iostat r/s 8 16 32 40 clients 33661 53502 86028 90616 fb56.handler 29120 49155 78748 88423 fb56.sql 33776 53702 86193 89755 orig57.handler 29244 49268 78801 88027 orig57.sql 26756 47813 65885 67840 tokumx32 23728 37442 41357 42089 tokumx64 18966 24440 25147 25322 mongo24 18312 25313 25701 25781 mongo26disk reads per query 8 16 32 40 clients 0.84a 0.84 0.84 0.84 fb56.handler 0.86 0.86 0.86 0.86 fb56.sql 0.85 0.84 0.84 0.84 orig57.handler 0.87 0.86 0.86 0.86 orig57.sql 2.12 2.10 2.09 2.10 tokumx32 2.34 2.28 2.25 2.29 tokumx64 1.48 1.46 1.44 1.45 mongo24 1.54 1.44 1.42 1.43 mongo26
Help fill the MySQL Track At SELF
Help fill up the MySQL track at the Southeast Linux Fest. RFP for #self2014 has been extended to Mon April 28th at 9 PM ET. Last chance! Get those talk submissions in!