Sep
01
2014
--

LinkedIn Is Quietly Retiring Network Visualization Tool InMaps

Screen Shot 2014-09-02 at 02.02.14 A little autumn cleaning underway at LinkedIn. The company is quietly retiring InMaps, a tool that let you map out how your LinkedIn network looks. A notice on the InMaps homepage notes that today, September 1, is the last day for you to use it, and that it is being discontinued so that LinkedIn “can focus on developing new ways to visualize your professional network.” As of… Read More

Sep
01
2014
--

Windows XP’s Market Share Fell By Less Than 1% In August

screen-shot-2014-03-04-at-10-44-21-am According to Net Applications, Windows XP’s global desktop market share fell from 24.82 percent in July, to 23.89 percent in August. That’s just under one percentage point in a full month. At that pace, it will take more than two years for Windows XP’s market share to fully dissipate. Read More

Sep
01
2014
--

Percona XtraDB Cluster 5.6.20-25.7 is now available

href="http://www.percona.com/blog/wp-content/uploads/2013/02/XtraDB-Cluster.jpg"> class="alignright size-full wp-image-12836" src="http://www.percona.com/blog/wp-content/uploads/2013/02/XtraDB-Cluster.jpg" alt="Percona XtraDB Cluster 5.6.20-25.7" width="237" height="82" />Percona is glad to announce the new release of href="http://www.percona.com/software/percona-xtradb-cluster">Percona XtraDB Cluster 5.6 on September 1st 2014. Binaries are available from href="http://www.percona.com/downloads/">downloads area or from our href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/installation.html">software repositories.

Based on Percona Server href="http://www.percona.com/doc/percona-server/5.6/release-notes/Percona-Server-5.6.20-68.0.html">5.6.20-68.0 including all the bug fixes in it, rel="nofollow" href="https://github.com/codership/galera/issues?milestone=1&page=1&state=closed" rel="nofollow">Galera Replicator 3.7, and on rel="nofollow" href="https://launchpad.net/wsrep-group/+milestone/5.6.20-25.6" rel="nofollow">Codership wsrep API 25.7, Percona XtraDB Cluster 5.6.20-25.7 is now the current General Availability release. All of Percona‘s software is open-source and free, and all the details of the release can be found in the rel="nofollow" href="https://launchpad.net/percona-xtradb-cluster/+milestone/5.6.20-25.7" rel="nofollow">5.6.20-25.7 milestone at Launchpad.

New Features:

  • New session variable wsrep_sync_wait has been implemented to control causality check. The old session variable wsrep_causal_reads is deprecated but is kept for backward compatibility ( rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1277053">#1277053).
  • rel="nofollow" rel="nofollow" href="http://freedesktop.org/wiki/Software/systemd/">systemd integration with RHEL/CentOS 7 is now available for Percona XtraDB Cluster from our testing repository ( rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1342223">#1342223).

Bugs Fixed:

  • Running START TRANSACTION WITH CONSISTENT SNAPSHOT, mysqldump with --single-transaction or mydumper with disabled binlog would lead to a server crash. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1353644">#1353644.
  • percona-xtradb-cluster-garbd-3.x package was installed incorrectly on Debian/Ubuntu. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1360633">#1360633.
  • Fixed netcat in SST script for CentOS 7 nmap-ncat. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1359767">#1359767.
  • TO isolation was run even when wsrep plugin was not loaded. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1358681">#1358681.
  • The error from net read was not handled in native MySQL mode. This would cause duplicate key error if there was unfinished transaction at the time of shutdown, because it would be committed during the startup recovery. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1358264">#1358264.
  • The netcat in garbd init script has been replaced with nmap for compatibility in CentOS 7. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1349384">#1349384.
  • SHOW STATUS was generating debug output in the error log. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1347818">#1347818.
  • Incorrect source string length could lead to server crash. This fix allows maximum of 3500 bytes of key material to be populated, longer keys will be truncated. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1347768">#1347768.
  • wsrep consistency check is now enabled for REPLACE ... SELECT as well. This was implemented because pt-table-checksum uses REPLACE .. SELECT during checksumming. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1343209">#1343209.
  • Client connections were closed unconditionally before generating SST request. Fixed by avoiding closing connections when wsrep is initialized before storage engines. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1258658">#1258658.
  • Session-level binlog_format change to STATEMENT is now allowed to support pt-table-checksum. A warning (to not use it otherwise) is also added to error log.

Other bug fixes: rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1280270">#1280270.

Release notes for Percona XtraDB Cluster href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/release-notes/Percona-XtraDB-Cluster-5.6.20-25.7.html">5.6.20-25.7 are available in our href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/index.html">online documentation along with the href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/installation.html">installation and href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/upgrading_guide_55_56.html">upgrade instructions.

Help us improve our software quality by reporting any bugs you encounter using our rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+filebug" rel="nofollow">bug tracking system. As always, thanks for your continued support of Percona!

The post rel="nofollow" href="http://www.percona.com/blog/2014/09/01/percona-xtradb-cluster-5-6-20-25-7-now-available/">Percona XtraDB Cluster 5.6.20-25.7 is now available appeared first on rel="nofollow" href="http://www.percona.com/blog">MySQL Performance Blog.

Sep
01
2014
--

Vandrico Wants To Become The Wearables Platform For The Workplace

unnamed (4) If you know about Vandrico, it’s probably because of the company’s cool wearables database we featured earlier this year. That was just a byproduct of Vandrico’s research, however. What the company is really about is bringing wearables into the workplace. Read More

Aug
31
2014
--

Galera replication – how to recover a PXC cluster

class="alignright" src="http://s2.percona.com/logo_percona_xtradbcluster_new.png" alt="" width="225" height="71" />

Galera replication for MySQL brings not only the new, great features to our ecosystem, but also introduces completely new maintenance techniques. Are you concerned about adding such new complexity to your MySQL environment? Perhaps that concern is unnecessarily.

I am going to present here some simple tips that hopefully will let fresh Galera users prevent headaches when there is the need to recover part or a whole cluster in certain situations. I used href="http://www.percona.com/software/percona-xtradb-cluster">Percona XtraDB Cluster (project based on Percona Server and Galera library + MySQL extensions from Codership) to prepare this post, but most if not all of the scenarios should also apply to any solution based on MySQL+Galera tandem you actually chose, whether these are rel="nofollow" href="http://galeracluster.com/downloads/#downloads" rel="nofollow">binaries from Codership, MariaDB Galera Cluster or maybe your own builds.

Unlike standard MySQL replication, a PXC cluster acts like one logical entity, which takes care about each node status and consistency as well as cluster status as a whole. This allows to maintain much better data integrity then you may expect from traditional asynchronous replication while allowing safe writes on multiple nodes in the same time. This is though for the price of more possible scenarios where database service will be stopped with no node being able to serve requests.

Lets assume the simplest case cluster of nodes A, B and C and few possible scenarios where some or all nodes are out of service. What may happen and what we have to do, to bring them (or whole cluster) back up.

Scenario 1

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g1.png"> class="alignright wp-image-25349 size-full" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g1.png" alt="g1" width="215" height="164" />Node A is gracefully stopped. Likely for the purpose of maintenance, configuration change, etc. /> In this case the other nodes receive “good bye” message from that node, hence the cluster size is reduced and some properties like quorum calculation or auto increment are automatically changed. Once we start the A node again, it will join the cluster based on it’s wsrep_cluster_address setting in my.cnf. This process is much different from normal replication – the joiner node won’t serve any requests until it is again fully synchronized with the cluster, so connecting to it’s peers isn’t enough, state transfer must succeed first. If the writeset cache ( href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#gcache.size">gcache.size), on nodes B and/or C has still all the transactions there were executed during the time this node was down, joining will be possible via (usually fast and light) rel="nofollow" href="http://galeracluster.com/documentation-webpages/statetransfer.html#incremental-state-transfer-ist" rel="nofollow">IST. Otherwise, full href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/manual/state_snapshot_transfer.html">SST will be needed, which in fact is full binary data snapshot copy. Hence it may be important here to determine the best donor, as shown in href="http://www.percona.com/blog/2014/01/08/finding-good-ist-donor-percona-xtradb-cluster-5-6/"> this article. If IST is impossible due to missing transactions in donor’s gcache, the fallback decision is made by the donor and SST is started automatically instead.

Scenario 2

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g2.png"> class="size-full wp-image-25348 alignright" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g2.png" alt="g2" width="211" height="160" />Nodes A and B are gracefully stopped. Similar to previous case, cluster size is reduced to 1, hence even the single remaining node C forms a rel="nofollow" href="http://galeracluster.com/documentation-webpages/weightedquorum.html#primary-component" rel="nofollow">primary component and is serving client requests. To get the nodes back into the cluster, you just need to start them. However, the node C will be switched to “Donor/Desynced” state as it will have to provide state transfer to at least first joining node. It is still possible to read/write to it during that process, but it may be much slower, depending how large state transfers it needs to send. Also some load balancers may consider the donor node as not operational and remove it from the pool. So it is best to avoid situation when only one node is up.

Note though, if you restart A and then B in that order, you may want to make sure B won’t use A as state transfer donor, as A may not have all the needed writesets in it’s gcache. So just specify the C node as donor this way (“nodeC” name is the one you specify with wsrep_node_name variable):

service mysql start --wsrep_sst_donor=nodeC

Scenario 3

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g3.png"> class="size-full wp-image-25347 alignright" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g3.png" alt="g3" width="211" height="157" />All three nodes are gracefully stopped. Cluster is deformed. In this case, the problem is how to initialize it again. Here, it is important to know, that during clean shutdown, a PXC node writes it’s last executed position into the grastate.dat file. By comparing the seqno number inside, you will see which node is the most advanced one (most likely the last one stopped). Cluster must be bootstrapped using this node, otherwise nodes that had more advanced position will have to perform full SST to join cluster initialized from the less advanced one (and some transactions will be lost). To bootstrap the first node, invoke the startup script like this:

/etc/init.d/mysql bootstrap-pxc

or

service mysql bootstrap-pxc

or

service mysql start --wsrep_new_cluster

or

service mysql start --wsrep-cluster-address="gcomm://"

or in packages using rel="nofollow" href="http://www.freedesktop.org/wiki/Software/systemd/" rel="nofollow">systemd service manager (Centos7 at the moment):

systemctl start mysql@bootstrap.service

In older PXC versions, to bootstrap cluster, you had to edit my.cnf and replace previous wsrep_cluster_address line with empty value like this: wsrep_cluster_address=gcomm:// and start mysql normally. More details to be found rel="nofollow" href="http://galeracluster.com/documentation-webpages/restartingcluster.html" rel="nofollow">here.

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g4.png"> class="size-full wp-image-25346 alignright" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g4.png" alt="g4" width="232" height="167" />Scenario 4

Node A disappears from the cluster. By disappear I mean power outage, hardware failure, kernel panic, mysqld crash, kill -9 on mysqld pid, OOMkiller, etc. Two remaining nodes notice the connection to A node is down and will be trying to re-connect to it. After some timeouts, both agree that node A is really down and remove it “officially” from the cluster. Quorum is saved ( 2 out of 3 nodes are up), so no service disruption happens. After restarting, A will join automatically the same way as in scenario 1.

Scenario 5

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g51.png"> class="wp-image-25364 size-full alignright" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g51.png" alt="" width="244" height="171" />Nodes A and B disappear. The node C is not able to form the quorum alone, so the cluster is switching into a non-primary mode, in which MySQL refuses to serve any SQL query. In this state, mysqld process on C will be still running, you can connect to it, but any statement related to data fails with:

mysql> select * from test.t1; /> ERROR 1047 (08S01): Unknown command

Actually reads will be possible for a moment until C decides that it cannot reach A and B, but immediately no new writes will be allowed thanks to the rel="nofollow" href="http://galeracluster.com/documentation-webpages/certificationbasedreplication.html" rel="nofollow">certification based replication in Galera. This is what we are going to see in the remaining node’s log:

140814 0:42:13 [Note] WSREP: commit failed for reason: 3 /> 140814 0:42:13 [Note] WSREP: conflict state: 0 /> 140814 0:42:13 [Note] WSREP: cluster conflict due to certification failure for threads: /> 140814 0:42:13 [Note] WSREP: Victim thread: /> THD: 7, mode: local, state: executing, conflict: cert failure, seqno: -1 /> SQL: insert into t values (1)

The single node C is then waiting for it’s peers to show up again, and in some cases if that happens, like when there was network outage and those nodes were up all the time, the cluster will be formed again automatically. Also if the nodes B and C were just network-severed from the first node, but they can still reach each other, they will keep functioning as they still form the quorum. If A and B were crashed ( due to data inconsistency, bug, etc. ) or off due to power outage, you need to do manual action to enable rel="nofollow" href="http://galeracluster.com/documentation-webpages/weightedquorum.html#primary-component" rel="nofollow">primary component on the C node, before you can bring A and B back. This way, we tell the C node “Hey, you can now form a new cluster alone, forget A and B!”. The command to do this is:

SET GLOBAL wsrep_provider_options='pc.bootstrap=true';

However, you should double check in order to be very sure the other nodes are really down before doing that! Otherwise, you will most likely end up with two clusters having different data.

Scenario 6

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g6.png"> class="size-full wp-image-25344 alignright" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g6.png" alt="g6" width="244" height="186" />All nodes went down without proper shutdown procedure. Such situation may happen in case of datacenter power failure, hitting some MySQL or Galera bug leading to crash on all nodes, but also as a result of data consistency being compromised where cluster detects that each node has different data. In each of those cases, the grastate.dat file is not updated and does not contain valid sequence number (seqno). It may look like this:

cat /var/lib/mysql/grastate.dat /> # GALERA saved state /> version: 2.1 /> uuid: 220dcdcb-1629-11e4-add3-aec059ad3734 /> seqno: -1 /> cert_index:

In this case, we are not sure if all nodes were consistent with each other, hence it is crucial to find the most advanced one in order to boostrap the cluster using it. Before starting mysql daemon on any node, you have to extract the last sequence number by checking it’s transactional state. You can do it this way:

[root@percona3 ~]# mysqld_safe --wsrep-recover /> 140821 15:57:15 mysqld_safe Logging to '/var/lib/mysql/percona3_error.log'. /> 140821 15:57:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql /> 140821 15:57:15 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.6bUIqM' --pid-file='/var/lib/mysql/percona3-recover.pid' /> 140821 15:57:17 mysqld_safe WSREP: Recovered position 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:2 /> 140821 15:57:19 mysqld_safe mysqld from pid file /var/lib/mysql/percona3.pid ended

So the last committed transaction sequence number on this node was 2. Now you just need to bootstrap from the latest node first and then start the others.

However, the above procedure won’t be needed in the recent Galera versions (3.6+?), available since href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/release-notes/Percona-XtraDB-Cluster-5.6.19-25.6.html">PXC 5.6.19. There is a new option – title="pc.recovery" href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#pc.recovery">pc.recovery (enabled by default), which saves the cluster state into a file named gvwstate.dat on each member node. As the variable name says (pc – primary component), it saves only a cluster being in PRIMARY state. An example content of that file may look like this:

cat /var/lib/mysql/gvwstate.dat /> my_uuid: 76de8ad9-2aac-11e4-8089-d27fd06893b9 /> #vwbeg /> view_id: 3 6c821ecc-2aac-11e4-85a5-56fe513c651f 3 /> bootstrap: 0 /> member: 6c821ecc-2aac-11e4-85a5-56fe513c651f 0 /> member: 6d80ec1b-2aac-11e4-8d1e-b2b2f6caf018 0 /> member: 76de8ad9-2aac-11e4-8089-d27fd06893b9 0 /> #vwend

We can see three node cluster above with all members being up. Thanks to this new feature, in the case of power outage in our datacenter, after power is back, the nodes will read the last state on startup and will try to restore primary component once all the members again start to see each other. This makes the PXC cluster to automatically recover from being powered down without any manual intervention!  In the logs we will see:

style="color: #0000ff;">140823 15:28:55 [Note] WSREP: restore pc from disk successfully /> (...) /> 140823 15:29:59 [Note] WSREP: declaring 6c821ecc at tcp://192.168.90.3:4567 stable /> 140823 15:29:59 [Note] WSREP: declaring 6d80ec1b at tcp://192.168.90.4:4567 stable /> 140823 15:29:59 [Warning] WSREP: no nodes coming from prim view, prim not possible /> 140823 15:29:59 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 2, memb_num = 3 /> 140823 15:29:59 [Note] WSREP: Flow-control interval: [28, 28] /> 140823 15:29:59 [Note] WSREP: Received NON-PRIMARY. /> 140823 15:29:59 [Note] WSREP: New cluster view: global state: 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:11, view# -1: non-Primary, number of nodes: 3, my index: 2, protocol version -1 /> 140823 15:29:59 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. /> style="color: #0000ff;">140823 15:29:59 [Note] WSREP: promote to primary component /> 140823 15:29:59 [Note] WSREP: save pc into disk /> 140823 15:29:59 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = yes, my_idx = 2, memb_num = 3 /> 140823 15:29:59 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID. /> 140823 15:29:59 [Note] WSREP: clear restored view /> (...) /> 140823 15:29:59 [Note] WSREP: Bootstrapped primary 00000000-0000-0000-0000-000000000000 found: 3. /> 140823 15:29:59 [Note] WSREP: Quorum results: /> version = 3, /> component = PRIMARY, /> conf_id = -1, /> members = 3/3 (joined/total), /> act_id = 11, /> last_appl. = -1, /> protocols = 0/6/2 (gcs/repl/appl), /> group UUID = 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a /> 140823 15:29:59 [Note] WSREP: Flow-control interval: [28, 28] /> 140823 15:29:59 [Note] WSREP: Restored state OPEN -> JOINED (11) /> 140823 15:29:59 [Note] WSREP: New cluster view: global state: 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:11, view# 0: Primary, number of nodes: 3, my index: 2, protocol version 2 /> 140823 15:29:59 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. /> 140823 15:29:59 [Note] WSREP: REPL Protocols: 6 (3, 2) /> 140823 15:29:59 [Note] WSREP: Service thread queue flushed. /> 140823 15:29:59 [Note] WSREP: Assign initial position for certification: 11, protocol version: 3 /> 140823 15:29:59 [Note] WSREP: Service thread queue flushed. /> 140823 15:29:59 [Note] WSREP: Member 1.0 (percona3) synced with group. /> 140823 15:29:59 [Note] WSREP: Member 2.0 (percona1) synced with group. /> 140823 15:29:59 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 11) /> 140823 15:29:59 [Note] WSREP: Synchronized with group, ready for connections

Scenario 7

href="http://www.percona.com/blog/wp-content/uploads/2014/08/g7.png"> class="alignright wp-image-25343 size-full" src="http://www.percona.com/blog/wp-content/uploads/2014/08/g7.png" alt="g7" width="508" height="167" />Cluster lost it’s primary state due to split brain situation. For the purpose of this example, let’s assume we have the cluster formed from even number of nodes – six and three of them are in one location while another three in second location (datacenter) and network connectivity is broken between them. Of course the best practice is to avoid such topology: if you can’t have odd number of real nodes, at least you can use an additional rel="nofollow" href="http://galeracluster.com/documentation-webpages/arbitrator.html" rel="nofollow">arbitrator (garbd) node or set higher href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#pc.weight">pc.weight to some nodes. But when split brain happens any way, so none of the separated groups can maintain the quorum – all nodes must stop serving requests and both parts of the cluster are just continuously trying to re-connect. If you want to restore the service even before the network link is restored, you can make one of the groups primary again using the same command like in scenario 5:

SET GLOBAL wsrep_provider_options='pc.bootstrap=true';

After that, you are able to work on the manually restored part of the cluster, and the second half should be able to automatically re-join using rel="nofollow" href="http://galeracluster.com/documentation-webpages/statetransfer.html#incremental-state-transfer-ist" rel="nofollow">incremental state transfer (IST) once the network link is restored. But beware: if you set the bootstrap option on both the separated parts, you will end up with two living cluster instances, with data likely diverging away from each other. Restoring network link in that case won’t make them to re-join until nodes are restarted and try to re-connect to members specified in configuration file. Then, as Galera replication model truly cares about data consistency – once the inconsistency will be detected, nodes that cannot execute row change statement due to different data – will perform emergency shutdown and the only way to bring them back to the cluster will be via full SST.

I hope I covered most of the possible failure scenarios of Galera-based clusters, and made the recovery procedures bit more clear.

The post rel="nofollow" href="http://www.percona.com/blog/2014/09/01/galera-replication-how-to-recover-a-pxc-cluster/">Galera replication – how to recover a PXC cluster appeared first on rel="nofollow" href="http://www.percona.com/blog">MySQL Performance Blog.

Aug
29
2014
--

Galera data on Percona Cloud Tools (and other MySQL monitoring tools)

I was talking with a href="http://www.percona.com/products/mysql-support" >Percona Support customer earlier this week who was looking for Galera data on Percona Cloud Tools. (Percona Cloud Tools, now in href="https://cloud.percona.com/" >free beta, is a hosted service providing access to query performance insights for all MySQL uses.)

The customer mentioned they were already keeping track of some Galera stats on title="Cacti" rel="nofollow" href="http://www.cacti.net/" rel="nofollow">Cacti, and given they were inclined to use  href="https://cloud.percona.com/" >Percona Cloud Tools more and more, they wanted to know if it was already supporting title="Percona XtraDB Cluster" href="http://www.percona.com/software/percona-xtradb-cluster">Percona XtraDB Cluster. My answer was: “No, not yet: you can install agents in each node (the regular way in style="color: #000000;"> the first node, then manually on the other nodes… and when prompted say “No” to create MySQL user and provide the one you’re using already) and monitor them as autonomous MySQL servers – but the concept of cluster and specially the “Galera bits” has yet to be implemented there.

Except I was wrong.

By “concept of cluster” I mean supporting the notion of style="text-decoration: underline;">group instances, which should allow a single cluster-wide view for metrics and query reports, such as the slow queries (which are recorded locally on the node where the query was run and thus observed in a detached way). This still needs to be implemented indeed, but it’s on the roadmap.

The “Galera bits” I mentioned above are the various “wsrep_” status variables. In fact, those refer to the Write Set REPlication patches (based in the title="wsrep: API for (a)synchronous writeset replication for transactional applications" rel="nofollow" href="https://launchpad.net/wsrep" rel="nofollow">wsrep API), a set of hooks applied to the InnoDB/XtraDB storage engine and other components of MySQL that modifies the way replication works (to put it in a very simplified way), which in turn are used by the  title="Galera librari" rel="nofollow" href="https://launchpad.net/galera">Galera library to provide a “generic Synchronous Multi-Master replication plugin for transactional applications.” A patched version of Percona Server together with the Galera libray compose the base of Percona XtraDB Cluster.

As I found out only now, Percona Cloud Tools style="text-decoration: underline;">does collect data from the various wsrep_ variables and it is available for use – it’s just not shown by default. A user only needs to add a dashboard/chart manually on PCT to see these metrics:

id="attachment_25412" style="width: 160px" class="wp-caption aligncenter"> href="http://www.percona.com/blog/wp-content/uploads/2014/08/adding_wsrep_chart.jpg"> class="wp-image-25412 size-thumbnail" src="http://www.percona.com/blog/wp-content/uploads/2014/08/adding_wsrep_chart-150x150.jpg" alt="adding_wsrep_chart" width="150" height="150" /> class="wp-caption-text">Click on the picture to enlarge it

Now, I need to call that customer …

Monitoring the cluster

Since I’m touching this topic I thought it would be useful to include some additional information on monitoring a Galera (Percona XtraDB Cluster in particular) cluster, even though most of what I mention below has already been published in different posts here on the MySQL Performance Blog. There’s a succint title="Monitoring the cluster" href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/manual/monitoring.html">documentation page bearing the same title of this section that indicates the main wsrep_ variables you should monitor to check the health status of the cluster and how well it’s coping with load along the time (performance). Remember you can get a grasp of the full set of variables at any time by issuing the following command from one (or each one) of the nodes:

mysql> SHOW GLOBAL STATUS LIKE "wsrep_%";

And for a broader and real time view of the wsrep_ status variables you can use Jay Janssen’s title="Jay Jansen's myq_gadgets on GitHub" rel="nofollow" href="https://github.com/jayjanssen/myq_gadgets/" rel="nofollow">myq_gadgets toolkit, which he title="Realtime stats to pay attention to in Percona XtraDB Cluster and Galera" href="http://www.percona.com/blog/2012/11/26/realtime-stats-to-pay-attention-to-in-percona-xtradb-cluster-and-galera/">modified a couple of years ago to account for Galera.

There’s also a specific title="Percona Galera/MySQL Monitoring Template for Cacti" href="http://www.percona.com/doc/percona-monitoring-plugins/1.1/cacti/galera-templates.html">Galera-template available in our title="http://www.percona.com/software/percona-monitoring-plugins" href="http://www.percona.com/software/percona-monitoring-plugins">Percona Monitoring Plugins (PMP) package that you can use in your title="Cacti" rel="nofollow" href="http://www.cacti.net/" rel="nofollow">Cacti server. That would cover the “how well the cluster copes with load along the time,” providing historical graphing. And while there isn’t a Galera specific plugin for Nagios in PMP, Jay title="Percona XtraDB Cluster/ Galera with Percona Monitoring Plugins" href="http://www.percona.com/blog/2013/10/31/percona-xtradb-cluster-galera-with-percona-monitoring-plugins/">explains in another post how you can customize  style="color: #047ac6;" title="pmp-check-mysql-status" href="http://www.percona.com/doc/percona-monitoring-plugins/1.1/nagios/pmp-check-mysql-status.html" shape="rect">pmp-check-mysql-status to “check any status variable you like,” describing his approach to keep a cluster’s “health status” in check by setting alerts on specific stats, on a per node basis.

VividCortex title="VIVIDCORTEX NOW SUPPORTS GALERA GRAPHS" rel="nofollow" href="https://vividcortex.com/blog/2014/08/04/galera-graphs/" rel="nofollow">recently added a set of templates for Galera in their product and you can also rely on Severalnines’ title="Severalnines' ClusterControl" rel="nofollow" href="http://www.severalnines.com/clustercontrol" rel="nofollow">ClusterControl monitoring features to get that “global view” of your cluster that Percona Cloud Tools doesn’t yet provide. Even though ClusterControl is a complete solution for cluster deployment and management, focusing on the automation of the whole process, the monitoring part alone is particularly interesting as it encompasses cluster-wide information in a customized way, including the “Galera bits”. You may want to give it a try as the monitoring features are available in the Community version of the product (and if you’re a Percona customer with a Support contract covering Percona XtraDB Cluster, then you’re entitled to get title="MySQL High Availability Cluster Monitoring Tools" href="http://www.percona.com/products/mysql-support/cluster-monitoring-solutions" >support for it from us).

One thing I should note that differentiate the monitoring solutions from above is that while you can install Cacti, Nagios and ClusterControl as servers in your own infrastructure both Percona Cloud Tools and VividCortex are hosted, cloud-based services. Having said that, neither title="From zero to full visibility of MySQL in 3 minutes with Percona Cloud Tools" href="http://www.percona.com/blog/2014/05/28/zero-full-visibility-mysql-3-minutes-percona-cloud-tools/">one nor the title="Privacy and Security" rel="nofollow" href="https://support.vividcortex.com/security/" rel="nofollow">other upload sensitive data to the cloud and both provide options for query obfuscation.

Summary

Contrary to what I believed, Percona Cloud Tools does provide support for “Galera bits” (the wsrep_ status variables), even though it has yet to implement support for the notion of group instances, which will allow for cluster-wide view for metrics and query reports. You can also rely on the Galera template for Cacti provided by Percona Monitoring Plugins for historical graphing and some clever use of Nagios’ pmp-check-mysql-status for customized cluster alerts. VividCortex and ClusterControl also provide monitoring for Galera.

Percona Cloud Tools, now in free beta, is a hosted service providing access to query performance insights for all MySQL uses. After a brief setup, unlock new information about your database and how to improve your applications. href="https://cloud.percona.com/" >Sign up to request access to the beta today.  

The post rel="nofollow" href="http://www.percona.com/blog/2014/08/29/galera-data-on-percona-cloud-tools-and-other-mysql-monitoring-tools/">Galera data on Percona Cloud Tools (and other MySQL monitoring tools) appeared first on rel="nofollow" href="http://www.percona.com/blog">MySQL Performance Blog.

Aug
29
2014
--

Percona Server 5.6.20-68.0 is now available

href="http://www.percona.com/blog/wp-content/uploads/2014/05/percona_server.jpeg"> class="alignright size-thumbnail wp-image-22759" src="http://www.percona.com/blog/wp-content/uploads/2014/05/percona_server-150x150.jpeg" alt="Percona Server" width="150" height="150" />Percona is glad to announce the release of href="http://www.percona.com/software/percona-server">Percona Server 5.6.20-68.0 on August 29, 2014. Download the latest version from the title="Percona Server 5.6" href="http://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.20-68.0/" >Percona web site or from the Percona href="http://www.percona.com/doc/percona-server/5.6/installation.html#using-percona-software-repositories">Software Repositories.

Based on MySQL rel="nofollow" href="http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html" rel="nofollow">5.6.20, including all the bug fixes in it, Percona Server 5.6.20-68.0 is the current GA release in the Percona Server 5.6 series. All of Percona’s software is open-source and free. Complete details of this release can be found in the rel="nofollow" href="https://launchpad.net/percona-server/+milestone/5.6.20-68.0" rel="nofollow">5.6.20-68.0 milestone on Launchpad.

New Features:

  • Percona Server has implemented the MySQL 5.7 SHOW SLAVE STATUS NONBLOCKING syntax for href="http://www.percona.com/doc/percona-server/5.6/reliability/show_slave_status_nolock.html#show-slave-status-nolock">Lock-Free SHOW SLAVE STATUS feature. The existing SHOW SLAVE STATUS NOLOCK is kept as a deprecated alias and will be removed in Percona Server 5.7. There were no functional changes for the feature.
  • Percona Server href="http://www.percona.com/doc/percona-server/5.6/management/audit_log_plugin.html#audit-log-plugin">Audit Log Plugin now supports JSON and CSV formats. The format choice is controlled by href="http://www.percona.com/doc/percona-server/5.6/management/audit_log_plugin.html#audit_log_format">audit_log_format variable.
  • Percona Server href="http://www.percona.com/doc/percona-server/5.6/management/audit_log_plugin.html#audit-log-plugin">Audit Log Plugin now supports href="http://www.percona.com/doc/percona-server/5.6/management/audit_log_plugin.html#streaming-to-syslog">streaming the audit log to syslog.
  • TokuDB storage engine package has been updated to version 7.1.8.

Bugs Fixed:

  • Querying href="http://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html#INNODB_CHANGED_PAGES">INNODB_CHANGED_PAGES table with a range condition START_LSN > x AND END_LSN < y would lead to a server crash if the range was empty with x greater than y. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1202252">#1202252 (Jan Lindström and Sergei Petrunia).
  • SQL statements of other connections were missing in the output of SHOW ENGINE INNODB STATUS, in LATEST DETECTED DEADLOCK and TRANSACTIONS sections. This bug was introduced by href="http://www.percona.com/doc/percona-server/5.6/management/statement_timeout.html#statement-timeout">Statement Timeout patch in Percona Server href="http://www.percona.com/doc/percona-server/5.6/release-notes/Percona-Server-5.6.13-61.0.html#5.6.13-61.0">5.6.13-61.0. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1328824">#1328824.
  • Some of TokuDB distribution files were missing in the TokuDB binary tarball. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1338945">#1338945.
  • With href="http://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html#changed-page-tracking">XtraDB changed page tracking feature enabled, queries from the href="http://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html#INNODB_CHANGED_PAGES">INNODB_CHANGED_PAGES could read the bitmap data whose write was in still progress. This would cause the query to fail with an ER_CANT_FIND_SYSTEM_REC and a warning printed to the server error log. The workaround has been to add an appropriate END_LSN-limiting condition to the query. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1193332">#1193332.
  • mysqld-debug was missing from Debian packages. This regression was introduced in Percona Server href="http://www.percona.com/doc/percona-server/5.6/release-notes/Percona-Server-5.6.16-64.0.html#5.6.16-64.0">5.6.16-64.0. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1290087">#1290087.
  • Fixed a memory leak in href="http://www.percona.com/doc/percona-server/5.6/flexibility/slowlog_rotation.html#slowlog-rotation">Slow Query Log Rotation and Expiration. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1314138">#1314138.
  • The audit log plugin would write log with XML syntax errors when OLD and NEW formats were used. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1320879">#1320879.
  • Combination of href="http://www.percona.com/doc/percona-server/5.6/management/log_archiving.html#log-archiving">Log Archiving for XtraDB, href="http://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html#changed-page-tracking">XtraDB changed page tracking, and small InnoDB logs could hang the server on the bootstrap shutdown. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1326379">#1326379.
  • --tc-heuristic-recover option values were broken. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1334330">#1334330 (upstream rel="nofollow" rel="nofollow" href="http://bugs.mysql.com/bug.php?id=70860">#70860).
  • If the bitmap directory has a bitmap file sequence with a start LSN of one file less than a start LSN of the previous file, a debug build would assert when queries were run on href="http://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html#INNODB_CHANGED_PAGES">INNODB_CHANGED_PAGES table. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1342494">#1342494.

Other bugs fixed: rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1337247">#1337247, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1350386">#1350386, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1208371">#1208371, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1261341">#1261341, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1151723">#1151723, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182050">#1182050, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182068">#1182068, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182072">#1182072, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1184287">#1184287, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1280875">#1280875, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1338937">#1338937, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1334743">#1334743, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1349394">#1349394, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182046">#1182046, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182049">#1182049, and rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1328482">#1328482 (upstream rel="nofollow" rel="nofollow" href="http://bugs.mysql.com/bug.php?id=73418">#73418).

Release notes for Percona Server 5.6.20-68.0 are available in the  href="http://www.percona.com/doc/percona-server/5.6/release-notes/Percona-Server-5.6.20-68.0.html">online documentation. Please report any bugs on the rel="nofollow" href="https://bugs.launchpad.net/percona-server/+filebug" rel="nofollow">launchpad bug tracker.

The post rel="nofollow" href="http://www.percona.com/blog/2014/08/29/percona-server-5-6-20-68-0-now-available/">Percona Server 5.6.20-68.0 is now available appeared first on rel="nofollow" href="http://www.percona.com/blog">MySQL Performance Blog.

Aug
29
2014
--

Percona Server 5.5.39-36.0 is now available

href="http://www.percona.com/blog/wp-content/uploads/2014/05/percona_server.jpeg"> class="alignright size-thumbnail wp-image-22759" src="http://www.percona.com/blog/wp-content/uploads/2014/05/percona_server-150x150.jpeg" alt="Percona Server" width="150" height="150" />Percona is glad to announce the release of  href="http://www.percona.com/software/percona-server">Percona Server 5.5.39-36.0 on August 29, 2014 (Downloads are available  href="http://www.percona.com/downloads/">here and from the  href="http://www.percona.com/doc/percona-server/5.5/installation.html">Percona Software Repositories). Based on  rel="nofollow" href="http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-39.html" rel="nofollow">MySQL 5.5.39, including all the bug fixes in it, Percona Server 5.5.39-36.0 is now the current stable release in the 5.5 series. All of Percona‘s software is open-source and free, all the details of the release can be found in the  rel="nofollow" href="https://launchpad.net/percona-server/+milestone/5.5.39-36.0" rel="nofollow">5.5.39-36.0 milestone at Launchpad.

New Features:

  • Percona Server href="http://www.percona.com/doc/percona-server/5.5/management/audit_log_plugin.html#audit-log-plugin">Audit Log Plugin now supports JSON and CSV formats. The format choice is controlled by href="http://www.percona.com/doc/percona-server/5.5/management/audit_log_plugin.html#audit_log_format">audit_log_format variable.
  • Percona Server href="http://www.percona.com/doc/percona-server/5.5/management/audit_log_plugin.html#audit-log-plugin">Audit Log Plugin now supports href="http://www.percona.com/doc/percona-server/5.5/management/audit_log_plugin.html#streaming-to-syslog">streaming the audit log to syslog.

Bugs Fixed:

  • Querying href="http://www.percona.com/doc/percona-server/5.5/management/changed_page_tracking.html#INNODB_CHANGED_PAGES">INNODB_CHANGED_PAGES with a range condition START_LSN > x AND END_LSN < y would lead to a server crash if the range was empty with x greater than y. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1202252">#1202252 (Jan Lindström and Sergei Petrunia).
  • With href="http://www.percona.com/doc/percona-server/5.5/management/changed_page_tracking.html#changed-page-tracking">XtraDB changed page tracking feature enabled, queries from the href="http://www.percona.com/doc/percona-server/5.5/management/changed_page_tracking.html#INNODB_CHANGED_PAGES">INNODB_CHANGED_PAGES could read the bitmap data whose write was in still progress. This would cause the query to fail with an ER_CANT_FIND_SYSTEM_REC and a warning printed to the server error log. The workaround has been to add an appropriate END_LSN-limiting condition to the query. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1346122">#1346122.
  • mysqld-debug was missing from Debian packages. This regression was introduced in Percona Server href="http://www.percona.com/doc/percona-server/5.5/release-notes/Percona-Server-5.5.36-34.0.html#5.5.36-34.0">5.5.36-34.0. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1290087">#1290087.
  • Fixed a memory leak in href="http://www.percona.com/doc/percona-server/5.5/flexibility/slowlog_rotation.html#slowlog-rotation">Slow Query Log Rotation and Expiration. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1314138">#1314138.
  • The audit log plugin would write log with XML syntax errors when OLD and NEW formats were used. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1320879">#1320879.
  • A server built with system OpenSSL support, such as the distributed Percona Server binaries, had SSL-related memory leaks. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1334743">#1334743 (upstream rel="nofollow" rel="nofollow" href="http://bugs.mysql.com/bug.php?id=73126">#73126).
  • If the bitmap directory has a bitmap file sequence with a start LSN of one file less than a start LSN of the previous file, a debug build would assert when queries were run on href="http://www.percona.com/doc/percona-server/5.5/management/changed_page_tracking.html#INNODB_CHANGED_PAGES">INNODB_CHANGED_PAGES table. Bug fixed rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1342494">#1342494.

Other bugs fixed: rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1337324">#1337324, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1151723">#1151723, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182050">#1182050, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182072">#1182072, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1280875">#1280875, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1182046">#1182046, rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1328482">#1328482 (upstream rel="nofollow" rel="nofollow" href="http://bugs.mysql.com/bug.php?id=73418">#73418), and rel="nofollow" rel="nofollow" href="https://bugs.launchpad.net/percona-server/+bug/1334317">#1334317 (upstream rel="nofollow" rel="nofollow" href="http://bugs.mysql.com/bug.php?id=73111">#73111).

Release notes for Percona Server 5.5.39-36.0 are available in our href="http://www.percona.com/doc/percona-server/5.5/release-notes/Percona-Server-5.5.39-36.0.html">online documentation. Bugs can be reported on the rel="nofollow" href="https://bugs.launchpad.net/percona-server/+filebug" rel="nofollow">launchpad bug tracker.

The post rel="nofollow" href="http://www.percona.com/blog/2014/08/29/percona-server-5-5-39-36-0-now-available/">Percona Server 5.5.39-36.0 is now available appeared first on rel="nofollow" href="http://www.percona.com/blog">MySQL Performance Blog.

Aug
28
2014
--

HP Desperately Wants To Be Innovative Again

Man and woman standing back to back in front of server towers. Let’s face it, HP was once the king of Silicon Valley, but over the last several years, the company has had issues due in part to the revolving door in the CEO office. While the company has finally gained some stability with Meg Whitman, the lack of consistent leadership has resulted in shifting priorities and changing strategies. And the products for which they were once so… Read More

Aug
28
2014
--

OpenStack Trove Day 2014 Recap: MySQL and DBaaS

id="attachment_25332" style="width: 149px" class="wp-caption alignright"> href="http://www.percona.com/blog/wp-content/uploads/2014/08/OpenStack-Trove-Day.jpg"> class="size-full wp-image-25332" src="http://www.percona.com/blog/wp-content/uploads/2014/08/OpenStack-Trove-Day.jpg" alt="OpenStack Trove Day" width="139" height="166" /> class="wp-caption-text">OpenStack Trove Day

I just returned from a week in Cambridge, Massachusetts where I was attending the title="OpenStack Trove Day" rel="nofollow" href="http://www.tesora.com/event/openstack-trove-day" rel="nofollow">OpenStack Trove Day and the Trove mid-cycle meetup, both sponsored by the great folks at Tesora.

I am relatively new to the OpenStack and Trove arenas so this was a fantastic opportunity for me to learn more about the communities, the various components within OpenStack, and what part Trove plays. I found the entire event very worthwhile – I met a lot of key people in the community, learned more about Trove and its potential, and in general felt a great energy and excitement surrounding Trove and OpenStack as a whole.

There were more than 120 attendees at Trove Day. That is almost four times the initial estimate! I think I would call that a success. There were 7 very high quality topics that covered material ranging from new and coming features within Trove, to deep inspection of how it is currently used in several big name companies to an investor’s perspective of the OpenStack market. There were also 2 panel style discussions that covered a lot of ground with all participants being ‘guys on the ground’ actively working with OpenStack deployments including one of my fellow Perconians, Mr. Tim Sharp.

One of the main takeaways for me from the entire day was the forward looking adoption estimates for Trove. This came up over and over through the various talks and panels. There seems to be a tremendous amount of interest in Trove deployments for late 2014/2015 but very few actual live users today. There also seems to be a bit of a messaging issue and confusion amongst potential users as to what Trove really is and is not. Simply reading the title="Trove Mission Statement" rel="nofollow" href="https://wiki.openstack.org/wiki/Trove" rel="nofollow">Trove Mission Statement should quickly clarify:

The OpenStack Open Source Database as a Service Mission: To provide scalable and reliable Cloud Database as a Service provisioning functionality for both relational and non-relational database engines, and to continue to improve its fully-featured and extensible open source framework.

So allow me to expand on that a bit based on some specific comments or questions that I overheard: /> – Trove is NOT a database abstraction layer nor any sort of database unification tool; all applications still communicate with their respective datastores directly through their native APIs. /> – Trove is NOT a database monitoring, management or analysis tool; all of your favorite debugging and monitoring tools like title="Percona Toolkit" href="http://www.percona.com/software/percona-toolkit">Percona Toolkit will still work exactly as advertised, and yes, you do need a monitoring tool. /> – Although Trove does have some useful backup scheduling options, Trove is NOT a complete backup and recovery tool that can accommodate every backup strategy; you may still use 3rd party options such as scripting your own around title="Percona XtraBackup" href="http://www.percona.com/software/percona-xtrabackup">Percona XtraBackup or make your life a lot easier and sign up for the title="Percona Backup Service" href="http://www.percona.com/products/percona-managed-services/percona-backup-service">Percona Backup Service. /> – Trove IS a very nice way to add resource provisioning for many disparate datastores and has some ‘smarts’ built in for each. This ensures a common user experience when provisioning and managing datastore instances.

To that final point, our friends at Tesora introduced their new title="Database Certification Program" rel="nofollow" href="http://www.tesora.com/news/press-releases/openstack-database-certification-program-announced-tesora" rel="nofollow">Database Certification Program at Trove Day. This new program will ensure a high level of compatibility between the various participating database vendors and the Trove project. Of course, Percona Server has already been certified.

I see the future of Trove as being very bright with a huge potential for expansion into other areas, once it is stabilized. I am very excited to begin contributing to this project and watch it grow.

Until next time…

The post rel="nofollow" href="http://www.percona.com/blog/2014/08/28/openstack-trove-day-2014-recap-mysql-and-dbaas/">OpenStack Trove Day 2014 Recap: MySQL and DBaaS appeared first on rel="nofollow" href="http://www.percona.com/blog">MySQL Performance Blog.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com