Percona MySQL University: Looking for a venue in Toronto next month

Percona CEO Peter Zaitsev leads a track at the inaugural Percona MySQL University event in Raleigh, N.C. on Jan. 29, 2013.

Percona CEO Peter Zaitsev leads a track at the inaugural Percona MySQL University event in Raleigh, N.C. on Jan. 29, 2013.

Thank you to everyone who attended Percona MySQL University in Raleigh, N.C. We had a great turnout and a lot of positive feedback!

What’s next for Percona MySQL University? Next week we’re going to hold events in Montevideo and Buenos Aires which are gathering significant local interest!

In March we’re focusing on Toronto – We’ll be having a team meeting and running an event at the same time to ensure that we have some great speakers available.

As such we’re looking for venue in Toronto to hold this Free MySQL Educational event. If you can host or can recommend a venue, give us a heads up.

Our requirement is essentially a single room with a projector hookup which can hold 100-150 people for a full day at a convenient local location.
Local universities or companies which may have a large enough meeting space have been a great fit for us in the past.

Please comment below if you are able to host or have some ideas on venues!

The post Percona MySQL University: Looking for a venue in Toronto next month appeared first on MySQL Performance Blog.


Feature in details: Incremental state transfer after a node crash in Percona XtraDB Cluster

With our newest release of Percona XtraDB Cluster, I would like to highlight a very nice ability to recovery a node and bring it back to the cluster with an incremental transfer after a crash.
This feature was available even in previous release, but now I want to give some details.

So, MySQL crashes from time to time and this a fact of life. HA solution is exactly needed to deal with an one node failure and allowing whole cluster continuing to work.

The idea is, if a node crashed, after it recovered – we just transfer all changes that happened in the cluster, while the node was down. It sounds easy in words, but proven hard when it comes to implementation. It all comes to the question: if mysqld crashes, how do we know what is the last transaction was executed. For a single InnoDB instance it is easy, there is always LSN, which is used for recovery, but in a cluster all nodes have their individual LSNs. Instead Cluster uses Global Transaction ID (GTID), in form
So, how can we store GTID so it is available after a crash? Of course there is always a good all way to store it in a separate file, which however will require an additional fsync call for each transaction, and it is know performance killer.

Instead, we store GTID in InnoDB system area, which is updated for each transaction. So even the system crashes, we can access information about the last commited transaction.
In XtraDB Cluster you can access this information by calling mysqld with option:
mysqld --wsrep-recover
and having this information, we can force the node to start forcing to use initial GTID:, i.e
mysqld --wsrep_start_position=50176f05-69b5-11e2-0800-930817fe924a:8549230

In fact the same methodology can be used if to restore nodes from backup.
We can start all nodes from an identical starting position, so they all will assume to start on identical data. Well, you can do it even on not identical data, but you know that you do not have a consistent cluster in this case.

As it all may sound complicated, this logic
--wsrep-recover / --wsrep_start_position= is implemented in mysqld_safe script, so you have it out of box.

Here is how a start process looks like in an error.log:

130129 23:01:22 mysqld_safe Starting mysqld daemon with databases from /mnt/data/mysql
130129 23:01:22 mysqld_safe WSREP: Running position recovery with --log_error=/tmp/tmp.l1zf2BIDja
130129 23:01:45 mysqld_safe WSREP: Recovered position 50176f05-69b5-11e2-0800-930817fe924a:8549230
130129 23:01:45 mysqld_safe WSREP: Recovered position 50176f05-69b5-11e2-0800-930817fe924a:8549230
130129 23:01:45 [Note] WSREP: wsrep_start_position var submitted: '50176f05-69b5-11e2-0800-930817fe924a:8549230'
130129 23:01:45 [Note] WSREP: Read nil XID from storage engines, skipping position init
130129 23:01:45 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/mysql/lib/libgalera_smm.so'
130129 23:01:45 [Note] WSREP: wsrep_load(): Galera 2.3(r143) by Codership Oy <info@codership.com> loaded succesfully.
130129 23:01:45 [Note] WSREP: Setting initial position to 50176f05-69b5-11e2-0800-930817fe924a:8549230
130129 23:01:56 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 8549242)
130129 23:01:56 [Note] WSREP: State transfer required: 
        Group state: 50176f05-69b5-11e2-0800-930817fe924a:8549242
        Local state: 50176f05-69b5-11e2-0800-930817fe924a:8549230
130129 23:01:58 [Note] WSREP: Prepared IST receiver, listening at: tcp://
130129 23:01:58 [Note] WSREP: Node 5 (node3) requested state transfer from '*any*'. Selected 0 (node1)(SYNCED) as donor.
130129 23:01:58 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 8549306)
130129 23:01:58 [Note] WSREP: Requesting state transfer: success, donor: 0
130129 23:01:58 [Note] WSREP: SST complete, seqno: 8549230
130129 23:02:01 [Note] WSREP: Receiving IST: 12 writesets, seqnos 8549230-8549242
130129 23:02:01 [Note] /usr/local/mysql/bin/mysqld: ready for connections.

So what happens there? Basically at start node detects that the last transaction had GTID:
50176f05-69b5-11e2-0800-930817fe924a:8549230, but joining cluster, it figures out
that the cluster already at position
and to catch up, the node has to recieve 12 events, which succesfully happen there:
130129 23:02:01 [Note] WSREP: Receiving IST: 12 writesets, seqnos 8549230-8549242

After applying 12 events locally the node is ready and succesfully joins cluster.

You may try it with the latest release Percona XtraDB Cluster 5.5.29

The post Feature in details: Incremental state transfer after a node crash in Percona XtraDB Cluster appeared first on MySQL Performance Blog.


Announcing Percona XtraDB Cluster 5.5.29-23.7.1

Percona is glad to announce the release of Percona XtraDB Cluster on January 30th, 2013. Binaries are available from downloads area or from our software repositories.

Bugs fixed:

  • In some cases when node is recovered variable threads_running would become huge. Bug fixed #1040108 (Teemu Ollakka).
  • Variable wsrep_defaults_file would be set up to the value in the last configuration file read. Bug fixed by keeping the value found in the top configuration file. Bug fixed #1079892 (Alex Yurchenko).
  • Variable wsrep_node_name was initialized before the glob_hostname, which lead to empty value for wsrep_node_name if it wasn’t set explicitly. Bug fixed #1081389 (Alex Yurchenko).
  • Running FLUSH TABLES WITH READ LOCK when slave applier needed to abort transaction that is on the way, caused the deadlock situation. Resolved by grabbing Global Read Lock before pausing wsrep provider. Bug fixed #1083162 (Teemu Ollakka).
  • Percona XtraDB Cluster would crash when processing a delete for a table with foreign key constraint. Bug fixed #1078346 (Seppo Jaakola).
  • When variable innodb_support_xa was set to 0, wsrep position wasn’t stored into the InnoDB tablespace. Bug fixed #1084199 (Teemu Ollakka).
  • Using XtraBackup for State Snapshot Transfer would fail due to mktemp error. Bug fixed #1080829 (Alex Yurchenko).
  • XtraBackup donor would run XtraBackup indefinitely if the xtrabackup --tmpdir was on tmpfs. Bug fixed #1086978 (Alex Yurchenko).
  • In some cases non-uniform foreign key reference could cause a slave crash. Fixed by using primary key of the child table when appending exclusive key for cascading delete operation. Bug fixed #1089490 (Seppo Jaakola).
  • Percona XtraDB Cluster would crash when binlog_format was set to STATEMENT. This was fixed by introducing the warning message. Bug fixed #1088400 (Seppo Jaakola).
  • An explicitly set wsrep_node_incoming_address might make “SHOW STATUS LIKE 'wsrep_incoming_addresses';” return the address without the port number. Bug fixed #1082406 (Alex Yurchenko).
  • Percona XtraDB Cluster would crash if the node’s own address would be specified in the wsrep_cluster_address variable. Bug fixed #1099413 (Alexey Yurchenko).
  • When installing from yum repository, Percona-XtraDB-Cluster-server and Percona-XtraDB-Cluster-client would conflict with mysql and mysql-server packages. Bug fixed #1087506 (Ignacio Nin).

Other bug fixes: bug fixed #1037165, bug fixed #812059.

Based on Percona Server 5.5.29-29.4 including all the bug fixes in it, Percona XtraDB Cluster 5.5.29-23.7.1 is now the current stable release. All of Percona‘s software is open-source and free.
We did our best to eliminate bugs and problems, but this is a software, so bugs are expected. If you encounter them, please report them to our bug tracking system.

The post Announcing Percona XtraDB Cluster 5.5.29-23.7.1 appeared first on MySQL Performance Blog.


How to start a Percona XtraDB Cluster

Before version 5.5.28 of Percona XtraDB Cluster, the easiest way was to join the cluster using wsrep_urls in [mysqld_safe] section of my.cnf.

So with a cluster of 3 nodes like this :

node1 =
node2 =
node3 =

we defined the setting like this :


With that line above in my.cnf on each node, when PXC (mysqld) was started, the node tried to join the cluster on the first IP, if no node was running on that IP, the next IP was tried and so on…. until the node could join the cluster or after it tried and didn’t find any node running the cluster, in that case mysqld failed to start.
To avoid this, when all nodes where down and you wanted to start the cluster, it was possible to have wsrep_urls defined like this :


That was a nice feature, especially for people that didn’t want to modify my.cnf after starting the first node initializing the cluster or people automating their deployment with a configuration management system.

Now, since wsrep_urls is deprecated since version 5.5.28 what is the better option to start the cluster ?

In my.cnf, [mysqld] section this time, you can use wsrep_cluster_address with the following syntax:


As you can see the port is not needed and gcomm:// is specified only once.

Note:In Debian and Ubuntu, the ip of the node cannot be present in that variable due to a glibc error:

130129 17:03:45 [Note] WSREP: gcomm: connecting to group 'testPXC', peer ',,'
17:03:45 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

So what can be done to initialize the cluster when all nodes are down ? There are two options:

  • modify my.cnf and set wsrep_cluster_address=gcomm:// then when the node is started change it again, this is not my favourite option.
  • start mysql using the following syntax (it works only on RedHat and CentOS out of the box):
    /etc/init.d/myslqd start --wsrep-cluster-address="gcomm://"
    As there is no need to modify my.cnf, this is how I recommend to do it.

The post How to start a Percona XtraDB Cluster appeared first on MySQL Performance Blog.


Feature preview: Compact backups in Percona XtraBackup

Percona XtraBackupWe continue to improve Percona XtraBackup, and today I would like to give a preview for one feature which comes in next Percona XtraBackup 2.1 release.

This feature is “Compact backups”, and let me explain what it does.
As you may know InnoDB PK (Primary Key) contains all data, and all secondary indexes are only subset of columns of Primary Key. So in theory we can store only PK, and re-build secondary indexes as we need. Well, now it is possible not only in theory.

To create a compact backup you should use
innobackupex --compact
and it will create a backup where all InnoDB tables contain only Primary Keys and not secondary.
It allows to safe some space on a backup storage. How much? Well, it depends on how many indexes you have.
For example for table order_line from tpcc benchmark, 100W.
Original size: 3140M,
Size in compact backup: 2228M.

You may suspect that there is a catch somewhere, and yes, there is.
To recovery a usable database, we need to rebuild indexes, and it is done on prepare stage,
and it takes time.
The command to prepare is:

innobackupex --apply-log --rebuild-indexes /data/backup

As a bonus, secondary indexes are created by sorting, that in general gives much less fragmented indexes, so it may result in an additional space saving.

In fact this --rebuild-indexes can be used on a full backup, and it will result in rebuilt de-fragmented indexes.

I encourage you to try this feature and report your experience.
Right now it is available only in source code from https://code.launchpad.net/~percona-core/percona-xtrabackup/2.1,
but preview binaries should be available soon.

The post Feature preview: Compact backups in Percona XtraBackup appeared first on MySQL Performance Blog.


How Can Percona MySQL Server Development Services Help ?

At Percona we offer a number of services. One of them, Custom MySQL Server Development, is commonly the most misunderstood and undervalued. There are a lot of ways Percona custom MySQL server development can help your business be more successful with MySQL. Here are some ways:

Bugs – There are Bugs in MySQL, Percona Server, and other products. By far the best and most cost efficient way to deal with Bugs is to have a Percona MySQL Support subscription which includes all you can eat bug fixes. If you need just one bug fixed this may be a way to go. Many bugs we’re tasked to fix are actually bugs in MySQL which the Oracle MySQL development team has not fixed. This does not only apply to “community reported bugs” as we had a number of customers who had an Oracle MySQL Support subscription but still could not get their relevant bug fixed in a prompt manner. The other possibility is you might get the bug fixed but in the wrong version of MySQL. If you’re running MySQL 5.1 but the bug is planned to be fixed only in MySQL 5.6, this might not be good enough for you. Percona MySQL Server Development Services can often Backport Bug Fixes in the version you’re running hence helping you to reduce upgrade costs and risks. We even can backport bugfixes to specific minor MySQL versions in many cases which can be important in some environments which focus on minimizing changes.

MySQL Version Compatibility – As new major MySQL versions are released they often have some incompatibilities ranging from very subtle to significant. In many cases it is easy to change the application to become compatible with a new MySQL version. In others, though, the application might be legacy or proprietary and changing it might not be an option so we can help with changes on the MySQL server side to make it work.

New Features in MySQL Server – In many cases you can get great value from new features added to MySQL which benefit your application a lot. I think many people do not even think about this option so they might come up with ugly workarounds for something which could be implemented on the MySQL server side relatively easily and then it can be controlled by the MySQL DBA team where it belongs instead of by by Application Developers. Sometimes a good workaround is not even possible; dynamic row format in memory engine is an example of such a feature.

Plugins – Plugins are a great way to implement new MySQL server features in many areas while keeping them easily maintainable. Customers have requested that we implement or include a numbers of plugins in Percona Server such as the Percona PAM authentication plugin or the HandlerSocket interface. If you have some custom authentication, auditing, or storage engine needs, we can help. It also might be more cost advantageous for you to work with us to implement the extra features from MySQL Enterprise Edition you need for your business rather than suffer from proprietary license lock-in.

Performance – We’re very good helping you to get the most performance from your MySQL server via our Percona MySQL Consulting, Percona MySQL Support, and Percona MySQL Remote DBA services. With our MySQL Server Development Services we can go even further and analyze your workload for code level optimization possibilities. We have seen a number of cases when optimizing for specific workload can provide substantial gains, ranging from tens of percents to 10x or more. For example, MySQL Optimizer doing a bad job in your circumstances which cannot be easily fixed with hints is one of those opportunities.

Custom Builds and Platform Support – Sometimes MySQL or Percona Server is not available for the platform you’re using. Other times you need a custom build with special compile time settings. Using Percona MySQL Server Development Services to do this work will ensure you get an optimal and tested build. We have seen many cases when compilation would be either done with settings for poor performance (such as debugging code enabled) or going overboard with unsafe optimization and not doing proper QA, resulting in stability issues.

In-House MySQL Dev Team Augmentation – A number of companies maintain an in-house MySQL build which can include community patches from various sources as well as some internally developed features. For example, shared hosting providers often implement features for abuse detection and prevention. Percona we can help you maintain your own tree or take the project over completely. Your features can remain your own – we will not force you to Open Source everything.

Percona Toolkit and Other Tools – So far I’ve been writing about MySQL Server only, though this is not the only software we can address. In fact, a lot of custom work we’re doing is on new tools, features, improvements, and bug fixes in tools like Percona Toolkit, Percona Xtrabackup, Percona Monitoring Plugins, and others.

Non-Percona Tools – Can we help you with non-Percona Tools, too? We have worked with a number of Open Source tools from the MySQL ecosystem and often we can either help you with the related development needs or we can help make an introduction to someone who can.

In Summary – There is a lot you can gain by taking a broad view of your MySQL server needs. Chances are custom MySQL server development should be one pillar of your strategy, and Percona MySQL Server Development Services can help with it, too.

The post How Can Percona MySQL Server Development Services Help ? appeared first on MySQL Performance Blog.


When the World falls apart

Well, all right, not the real world, just the world I am currently writing about in my second book. “Oh,” you say, disregarding the whole thing, but for an author this is a big deal.

When it comes to planning, there are two types of authors: “Pansters”, so called because they write by the seat of their pants. They have a rough idea of their characters and where the plot is heading, but essentially make it up as they go along. Then there are “outliners” – my camp. We plan everything in advance, scene by scene, often in spreadsheets or on index cards. We carefully craft how the plot unfolds, the foreshadowing, who does what, when and to whom. It’s all there before we write, like directions from Google Maps.

Am I painting the impression that outliners are superior? *Laugh* Not at all. There is no correct way, and many authors take a hybrid approach. Actually, I envy the freedom that “pantsers” enjoy, and admire their ability to pull a book together on the fly. I’ve tried their approach and it didn’t work for me. I’m an engineer. I don’t think that way. Oh, all, right, I’m anal. It’s true!

So, here I am, happily half way through writing my current book, and bang! It falls apart. In a moment of total horror, I realize that the whole second half isn’t going to work – it will be confusing, unbelievable and probably very unsatisfying for the reader. Arg!

This happened on my first book, “Ocean of Dust“, too. I suspect that it happens to many authors. That first time, I panicked: “I can’t write!” “This book’s too hard,” “I should just give up and shred it all.” But I persevered, (obviously because my book is published *smile*) and went back to the drawing board. At the forefront of my mind was “what would entertain the reader?” I re-planned half the book, rewriting as little of the first half as possible.

What makes a book go off the rails like that? Many, many things. Plotting an entire book before you write a single word is a challenge, and that is the chief drawback of being an outliner. An outline is just a sequence of scenes with a few paragraphs of notes about each one. Sure, I can imagine the character’s goals and motivations at each stage, consider what they learn, how they adapt; but it’s just not possible to think of every angle.

As I actually write each scene, I’m in the moment with my characters. Suddenly, it might make more sense for them to do this rather than that. As the sentences flow, I consider that another idea is more entertaining that my current one; maybe it would add more tension, more drama. Setting this in an inn is clichéd, how about a street market? That’s silly that my hero could defeat the guards so easily, how about this…? All the time, I am making small deviations from my outline.

These minute deviations act like a Butterfly Effect. Before I know it, the ripples moving through my book have become tidal waves, waves strong enough to break future scenes, to rip a hole in the fabric of space itself! Well, a hole in my outline, anyway.

At the same time, I might be making changes that are more sweeping. There’s a flaw in one of my story-arcs, perhaps because my character did something different than my outline told him too. His act made sense three scenes ago when I was in his head. Sometimes my writing group or beta readers will hate a character or a scene. Maybe it was… shock, horror… boring!

When you think about it, almost nothing in life goes according to plan. It requires constant course changes in light of more recent information. Maybe those pantsers have something after all? Sometimes, you have to head in a different direction entirely. So why should writing a book be any different?

And it isn’t, of course. It just seems like a catastrophe because creative pursuits like writing tap more into the id and superego. An artist in any field will describe similar feelings of baring one’s soul to create their chosen form of art. We are no longer hiding behind our everyday mask, but bringing forth inner imaginations and showing them to the world. When this goes wrong, when my plot falls apart, it is a direct blow to my id.

Such are the challenges of writing a novel. It hurts to have hit one’s writing stride only to come to a screeching halt, and have to rethink everything. But it’s a great excuse for revisiting the plot in light of what has been written, and using all that extra knowledge to build a stronger book, a more exciting book, with a richer, more powerful second half. The caring author thinks not of the extra work, but delivering a better experience for the reader.



MySQL 5.6: Improvements in the Nutshell

Preparing for my talk for Percona MySQL University in Raleigh,NC, Tuesday 29th of January I have created the outline of improvements available in MySQL 5.6 which I thought was worth sharing to give a feel for how massive work have been done for this release in variety of areas. I’m sure the list is not complete so If I miss something significant please let me know through the comment and I’ll update the page

– Scalable Read Only Transactions
– Concurrent Innodb data file extension
– Non-Recursive Deadlock Detection
– Faster Locking Primitives
– Improved Innodb Thread Concurrency
– Multiple background Purge Threads
– Improved Purge lag control (now works)
– Split of “Kernel Mutex”
– Data Dictionary Cache
– Improved Adaptive Flushing
– Page Cleaner/Separate Flush Thread
– Group Commit for Binary Log
– Fight Cache Coherence and False Sharing issues
– Reduced Innodb Memory Fragmentation
– Reduced Locking for Partitioned tables
– Reduced Contention for LOCK_open
– Support for multiple table_open_cache instances
– Large (over 4GB) redo logs support

Optimizer and Execution
– Index Condition pushdown (ICP)
– Multi-Range-Read (MRR)
– Faster ORDER BY nidxcol LIMIT N
– Persistent Statistics for Innodb
– Improvements to Innodb Compression
– Fast Page Checksums (CRC32)
– 4K and 8K Page sizes for Innodb
– Improvement to Buffer Pool Flushing
– Subquery Optimizations
– More efficient Optimizer

– Optimized ROW Based Replication
– Multi-Threaded Slave
– Global Transaction Identifiers
– Crash Safe Slave and Binlog
– Replication Event Checksums
– Time Delayed Replication
– Server UUID
– Improved Logging for Row based Replication
– Replication Utilities for Failover and Admin

– – Meta Data Information Tables
– – Buffer Pool Information Tables
– – Reduced Overhead
– – Simplified Configuration
– – Table Access instrumentation
– – Statements instrumentation
– – Stages Instrumentation
– – Aggregations by User, Host etc
– – Network IO Instrumentation
– – Show Host Cache Contents
– – Improved File I/O Instrumentation
– Improved EXPLAIN
– – Explain for UPDATE/DELETE queries
– – JSON output with more information
– Optimizer Tracing
– Deadlock Logging

Operational Improvements
– Separate Tablespaces for Innodb Undo Logs
– Fast Restart – Preloading Innodb Buffer Pool
– Online DDL
– Import/Export for Partitioned Tables
– Remote Binlog Backup
– Innodb Transportable Tablespaces
– New configuration files defaults
– User Defined DATA DIRECTORY for Innodb Tables
– Connection Attributes

New Functionality for Developers
– MemcacheD API in Innodb
– Explicit Partition Selection in queries
– Full Text Search index for Innodb
– Microsecond TIME precision
– Precise spatial operations in GIS

– Password hashes instead of plain passwords in Query Logs
– SHA256 hashing with Salt for Authentication
– Use obfuscated password storage for command line tools
– Policy Based password validation
– Plugin authentication support for Replication

The post MySQL 5.6: Improvements in the Nutshell appeared first on MySQL Performance Blog.


Percona MySQL University in Montevideo and Buenos Aires

Following our Percona MySQL University event in Raleigh,NC Percona MySQL University comes to South America! We’ll have a Full day FREE MySQL Technical Educational events in Montevideo on February 5th, 2013 and Buenos Aires on February 7th.

I’m very excited to bring these events to MySQL Community in Uruguay and Argentina. This is my first trip to South America and it looks like it is going to be a lot of fun!

With Percona MySQL University events, we focus on MySQL Education for broad group of users. We’ve specially prepared talks that will be interesting for people just starting with MySQL to experienced MySQL developers and DBAs. So whether you’re a college student or an experienced MySQL professional, you should find something of value.

Two of very exciting topics we’re going to cover are discussions on MySQL 5.6 with “MySQL 5.6: Advantages in a nutshell” as well as  the great new Replication an Clustering solution for MySQL based on Galera technology with “High availability and clustering with Percona XtraDB Cluster.” Some of the talks are going to be delivered in Spanish.

The event will also provide great networking opportunities and I hope you will make many new friends in MySQL Space from attending this event.

Finally let me thank the ORT University and Gallito for supporting Percona MySQL University in Montevideo.

Space is limited so do not delay, register now for Montevideo or Buenos Aires!

The post Percona MySQL University in Montevideo and Buenos Aires appeared first on MySQL Performance Blog.


Announcing Percona Server 5.1.67-14.3

Percona is glad to announce the release of Percona Server 5.1.67-14.3 on January 23rd, 2013 (Downloads are available here and from the Percona Software Repositories).

Based on MySQL 5.1.67, including all the bug fixes in it, Percona Server 5.1.67-14.3 is now the current stable release in the 5.1 series. All of Percona‘s software is open-source and free, all the details of the release can be found in the 5.1.67-14.3 milestone at Launchpad.

Bugs Fixed:

  • Fixed the upstream bug #68045 and ported a fix for the security vulnerability CVE-2012-4414 from the Percona Server 5.1.66-14.2. This bug fix replaces the upstream fix for the MySQL bug #66550. More details about this can be found in Stewart’s blogpost. Bug fixed #1049871 (Vlad Lesin).

Other bug fixes: bug fixed #1087202 (Vladislav Vaintroub, Laurynas Biveinis) and bug fixed #1087218 (Vladislav Vaintroub, Laurynas Biveinis).

Release notes for Percona Server 5.1.67-14.3 are available in our online documentation. Bugs can be reported on the launchpad bug tracker.

The post Announcing Percona Server 5.1.67-14.3 appeared first on MySQL Performance Blog.

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