Auditing your database means tracking access and changes to your data and db objects. The Audit Log Plugin has been shipped with Percona Server since 5.5.37/5.6.17, for a little over 12 months. Prior to the Audit Log Plugin, you had to work in darker ways to achieve some incarnation of an audit trail.
We have seen attempts at creating audit trails using approaches such as ‘sniffing the wire’, init files, in-schema ‘on update’ fields, triggers, proxies and trying to parse the traditional logs of MySQL (slow, general, binary, error). All of these attempts miss a piece of the pie, i.e. if you’re sniffing …[Read more...]
Percona Server 5.6.21+ and MySQL 5.7.8+ offer the
super_read_only option that was first
implemented in WebscaleSQL. Unlike
option prevents all users from running writes (even those with
the SUPER privilege). Sure enough, this is a great feature, but
what’s the relation with GTID? Read on!
super_read_only on all slaves when using
GTID replication makes your topology far less sensitive to errant
transactions. Failover is then easier and safer because …
In MySQL QA Episode #12, “MySQL is Crashing, now what?,” Roel demonstrated how to collect crash-related information that will help Percona discover what the issue is that you are experiencing, and fix it.
As a Support Engineer I (Sveta) am very happy to see this post – but as a person who better understands writing than recording – I’d like to have same information, in textual form. We discussed it, and decided to do a joint blog post. Hence, this post …[Read more...]
Previously I tested Tokutek’s Fractal Trees (TokuMX & TokuMXse) as MongoDB storage engines – today let’s look into the MySQL area.
I am going to use modified LinkBench in a heavy IO-load.
I compared InnoDB without compression, InnoDB with 8k
compression, TokuDB with quicklz compression.
Uncompressed datasize is 115GiB, and cachesize is 12GiB for InnoDB and 8GiB + …
I recently worked with a customer who had a weird issue: when
their MySQL server was started (Percona Server 5.5), if they try
service mysql start a second time, the init
script was not able to detect that an instance was already
running. As a result, it tried to start a second instance with
the same settings as the first one. Of course this fails and this
creates a mess. What was the issue? A missing rule in SELinux. At
least it looks like
If SELinux is set to enforcing and if you are using Percona
Server on CentOS/RHEL 6 (other versions could be affected),
service mysql start doesn’t work properly …