If you are using Percona XtraBackup with
xbcrypt
to create encrypted backups, and are using versions older than 2.3.6 or 2.4.5, we advise that you upgrade Percona XtraBackup.
Note: this does not affect encryption …
[Read more]If you are using Percona XtraBackup with
xbcrypt
to create encrypted backups, and are using versions older than 2.3.6 or 2.4.5, we advise that you upgrade Percona XtraBackup.
Note: this does not affect encryption …
[Read more]
The details on this issue are here:
https://github.com/facebook/mysql-5.6/issues/369
This test is very simple. I loaded the SSB (star schema
benchmark) data for scale factor 20 (12GB raw data), added
indexes, and tried to count the rows in the table.
After loading data and creating indexes, the .rocksdb data
directory is 17GB in size.
A full table scan "count(*)" query takes less than four minutes,
sometimes reading over 1M rows per second, but when scanning the
index to accomplish the same count, the database can only scan
around 2000 rows per second. The four minute query would take an
estimated 1000 minutes, a 250x difference.
I have eliminated the type of CRC32 function (SSE vs non-SSE) by
forcing the hardware SSE function by patching the code.
There seem to be problems with any queries …
The details on this issue are here:
https://github.com/facebook/mysql-5.6/issues/369
This test is very simple. I loaded the SSB (star schema
benchmark) data for scale factor 20 (12GB raw data), added
indexes, and tried to count the rows in the table.
After loading data and creating indexes, the .rocksdb data
directory is 17GB in size.
A full table scan "count(*)" query takes less than four minutes,
sometimes reading over 1M rows per second, but when scanning the
index to accomplish the same count, the database can only scan
around 2000 rows per second. The four minute query would take an
estimated 1000 minutes, a 250x difference.
I have eliminated the type of CRC32 function (SSE vs non-SSE) by
forcing the hardware SSE function by patching the code.
…
One of the main tasks that any DBA has to deal with is certainly
data retention. Especially when your developers like to store
logging and tracking information inside the database. This is not
something that I would recommend (don't try it at home!) but when
you're late to the party (read: someone had taken this path
before you joined) , then you'll have to live with it.
Data retention in MySQL is usually applied by partitioning the
table by RANGE on a selected column, usually containing the row
creation timestamp. New partitions are created in advance for the
coming days or weeks or months, and a script is used that will
run nightly and drop partitions that are older than a set
retention.
There are many tools that can be used to automate data retention;
I have chosen the excellent pdb-parted, a nice and cozy perl
script that you can find in the PalominoDB repository on GitHub
(since PalominoDB is no longer in existence, …
If there is something that I love about information technology is
the incredible amount of unpredictable ways that bugs can bite
you where and when you less expect it.
This one I'm about to describe is a serious one, yet there has
been a very quiet response from Percona bug team at Launchpad,
where I first submitted it (because we use Percona server here).
If you have read my other posts you know by now that I am a
laz... err, busy guy so bear with me if only today I have
verified that this is, in fact, an upstream bug and have raised a
bug to Oracle too.
It affects 5.6.33, latest version at the time of this
article.
Anyways, the bug started to manifest itself in the form of
complete stalls of our main cluster, which was happening at
different times and apparently in a way that was unrelated to the
amount of traffic hitting the master. When stalling, system
CPU time was topping 100% of total available …
A question which would come sometimes to mind when starting with
MySQL is whether I should use DATETIME or TIMESTAMP data type
since both appear to store same date and time component.
Similarities between datetime and timestamp:
1. Values contain both date and time parts.
2. Format of retrieval and display is "YYYY-MM-DD
HH:MM:SS".
3. Can include a trailing fractional seconds part in up to
microseconds (6 digits) precision.
4. With the fractional part included, the format for these values
is "YYYY-MM-DD HH:MM:SS[.fraction]".
5. Both the TIMESTAMP and (as of MySQL 5.6.5) DATETIME offer
automatic initialization and updating to the current …
Auf der FrOSCon 10 in St. Augustin habe ich kürzlich ein Update zu unseren Erfahrungen mit dem Thema "Private Cloud mit OpenSource" gegeben. Leider sind noch nicht alle Probleme, über die letztes Jahr berichtet wurde, behoben, aber wir sind schon ein gutes Stück weiter und haben neue Stolperfallen gefunden und z. T. auch überwunden.
Leider habe ich mich mit der Zeit ein wenig getäuscht, da ich den Talk vorher schon einmal in gekürzter Form in 40 Minuten unterbringen musste, aber in der Präsentation den Countdown für die FrOSCon wieder auf 60 Minuten zu stellen vergessen hatte. Zwischenzeitlich war ich deswegen der Meinung, ziemlich hinterherzuhängen... Hoffe, es macht trotzdem ein bisschen Spaß, so blieb am Ende mehr Zeit für Fragen und Gespräche :)
Hier noch die Folien auf Slideshare:
…
[Read more]Over on the codecentric blog I just published a new post on True KVM Live Migration with OpenStack Icehouse and Ceph based VM storage, outlining the process it took me to get this actually working. There were several issues to work around, some of them bugs in OpenStack, some of them home-grown issues.
I provide a few patches to OpenStack classes as well as a description of what is actually going wrong and how to circumvent the problems. So head right over and have fun reading :)
Today as i was learning for the new MySQL 5.6-certification (more about that in a later post) i stumbled again across the host_cache-Table that was added to MySQL in 5.6.5. Before that you had no chance to check which hosts are already known by the MySQL-server.
So thats a pretty good feature for us. And even better: you could resize the size of the host_cache now! Whoohoo, awesome! As we have a lot of servers that need to connect to one of our MySQL-server and we could not switch to ip-based-authentication we were really happy to tune the host_cache-size without recompiling MySQL.
Unfortunately i noticed that the performance_schema.host_cache table only holds 128 rows and that the content was changing everytime i checked. So i logged in to a server that wasn’t already in the host_cache-table, made a connection attempt to the mysql server and checked again the host_cache-table:
The server was now in the …
[Read more]Recently i updated to MySQL 5.6 and we were really excited about the very good overall performance. But beside a major bug concerning wrong results when running a SELECT that includes a HAVING based on a function (see http://bugs.mysql.com/bug.php?id=69638) we also noticed that from time to time the replication breaks with the following error:
Last_SQL_Errno: 1590 Last_SQL_Error: The incident LOST_EVENTS occured on the master. Message: error writing to the binary log
After some investigation it seemed like this happens if one modifies some user privileges, so we stumbled upon http://bugs.mysql.com/bug.php?id=68892.
Essentially the bug report says that if you use the wrong syntax for GRANT-statements the replication will break. So far, so bad. I told everyone who had the …
[Read more]