Jul
23
2014
--

DBaaS, OpenStack and Trove 101: Introduction to the basics

We’ll be publishing a series of posts on OpenStack and Trove over the next few weeks, diving into their usage and purpose. For readers who are already familiar with these technologies, there should be no doubt as to why we are incredibly excited about them, but for those who aren’t, consider this a small introduction to the basics and concepts.

What is Database as a Service (DBaaS)? /> In a nutshell, DBaaS – as it is frequently referred to – is a loose moniker to the concept of providing a managed cloud-based database environment accessible by users, applications or developers. Its aim is to provide a full-fledged database environment, while minimizing the administrative turmoil and pains of managing the surrounding infrastructure.

Real life example: Imagine you are working on a new application that has to be accessible from multiple regions. Building and maintaining a large multiregion setup can be very expensive. Furthermore, it introduces additional complexity and strain on your system engineers once timezones start to come into play. The challenge of having to manage machines in multiple datacenters won’t simplify your release cycle, nor increase your engineers’ happiness.

Let’s take a look at some of the questions DBaaS could answer in a situation like this:

- How do I need to size my machines, and where should I locate them? /> Small environments require less computing power and can be a good starting point, although this also means they may not be as well-prepared for future growth. Buying larger-scale and more expensive hardware and hosting can be very expensive and can be a big stumbling block for a brand new development project. Hosting machines in multiple DC’s could also introduce administrative difficulties, like having different SLA’s and potential issues setting up WAN or VPN communications. DBaaS introduces an abstraction layer, so these consideration aren’t yours, but those of the company offering it, while you get to reap all the rewards.

- Who will manage my environment from an operational standpoint? /> Staffing considerations and taking on the required knowledge to properly maintain a production database are often either temporarily sweeped under the rug or, when the situation turns out badly, a cause for the untimely demise of quite a few young projects. Rather than think about how long ago you should have applied that security patch, wouldn’t it be nice to just focus on managing the data itself, and be otherwise confident that the layers beyond it are managed responsibly?

- Have a sudden need to scale out? /> Once you’re up and running, enjoying the success of a growing use base, your environment will need to scale accordingly. Rather than think long and hard on the many options available, as well as the logistics attached to those changes, your DBaaS provider could handle this transparently.

Popular public options: Here are a few names of public services you may have come across already that fall under the DBaaS moniker:

- Amazon RDS /> – Rackspace cloud databases /> – Microsoft SQLAzure /> – Heroku /> – Clustrix DBaaS

What differentiates these services from a standard remote database is the abstraction layer that fully automates their backend, while still offering an environment that is familiar to what your development team is used to (be it MySQL, MongoDB, Microsoft SQLServer, or otherwise). A big tradeoff to using these services is that you are effectively trusting an external company with all of your data, which might make your legal team a bit nervous.

Private cloud options? /> What if you could offer your team the best of both worlds? Or even provide a similar type of service to your own customers? Over the years, a lot of platforms have been popping up to allow effective management and automation of virtual environments such as these, allowing you to effectively “roll your own” DBaaS. To get there, there are two important layers to consider:

  • Infrastructure Management, also referred to as Infrastructure-as-a-Service (IaaS), focusing on the logistics of spinning up virtual machines and keeping their required software packages running.
  • Database Management, previously referred to DBaaS, transparently coordinating multiple database instances to work together and present themselves as a single, coherent data repository.

Examples of IaaS products: /> – OpenStack /> – OpenQRM

Ecample of DBaaS: /> – Trove

Main Advantages of DBaaS /> For reference, the main reasons why you might want to consider using an existing DBaaS are as follows:

- Reduced Database management costs

DBaaS removes the amount of maintenance you need to perform on isolated DB instances. You offload the system administration of hardware, OS and database to either a dedicated service provider, or in the case where you are rolling your own, allow your database team to more efficiently manage and scale the platform (public vs private DBaaS).

- Simplifies certain security aspects

If you are opting to use a DBaaS platform, the responsibility of worrying about this or that patch being applied falls to your service provider, and you can generally assume that they’ll keep your platform secure from the software perspective.

- Centralized management

One system to rule them all. A guarantee of no nasty surprises concerning that one ancient server that should have been replaced years ago, but you never got around to it. As a user of DBaaS, all you need to worry about is how you interface with the database itself.

- Easy provisioning

Scaling of the environment happens transparently, with minimal additional management.

- Choice of backends

Typically, DBaas providers offer you the choice of a multitude of database flavors, so you can mix and match according to your needs.

Main Disadvantages /> - Reduced visibility of the backend

Releasing control of the backend requires a good amount of trust in your DBaaS provider. There is limited or no visibility into how backups are run and maintained, which configuration modifications are applied, or even when and which updates will be implemented. Just as you offload your responsibilities, you in turn need to rely on an SLA contract.

- Potentially harder to recover from catastrophic failures

Similarly to the above, unless your service providers have maintained thorough backups on your behalf, the lack of direct access to the host machines means that it could be much harder to recover from database failure.

- Reduced performance for specific applications

There’s a good chance that you are working on a shared environment. This means the amount of workload-specific performance tuning options is limited.

- Privacy and Security concerns

Although it is much easier to maintain and patch your environment. Having a centralized system also means you’re more prone to potential attacks targeting your dataset. Whichever provider you go with, make sure you are intimately aware of the measures they take to protect you from that, and what is expected from your side to help keep it safe.

Conclusion: While DBaaS is an interesting concept that introduces a completely new way of approaching an application’s database infrastructure, and can bring enterprises easily scalable, and financially flexible platforms, it should not be considered a silver bullet. Some big tradeoffs need to be considered carefully from the business perspective, and any move there should be accompanied with careful planning and investigation of options.

Embracing the immense flexibility these platforms offer, though, opens up a lot of interesting perspectives too. More and more companies are looking at ways to roll their own “as-a-Service”, provisioning completely automated hosted platforms for customers on-demand, and abstracting their management layers to allow them to be serviced by smaller, highly focused technical teams.

Stay tuned: Over the next few weeks we’ll be publishing a series of posts focusing on the combination of two technologies that allow for this type of flexibility: OpenStack and Trove.

The post rel="nofollow" href="http://www.mysqlperformanceblog.com/2014/07/24/dbaas-openstack-and-trove-101-introduction-to-the-basics/">DBaaS, OpenStack and Trove 101: Introduction to the basics appeared first on rel="nofollow" href="http://www.mysqlperformanceblog.com/">MySQL Performance Blog.

Jul
23
2014
--

New Infosys CEO Vishal Sikka Prepares To Take The Helm

Ocean wave It’s been a whirlwind few months for Vishal Sikka. It began when he suddenly left his job as executive and head of products at SAP at the beginning of May and it has continued as he prepares to take the helm at Infosys on August 1st. When I spoke to him at the end of May, just ahead of the SAP Sapphire Conference,  he seemed at peace with his decision to leave SAP in spite of the… Read More

Jul
23
2014
--

Dropbox Gets Down To Business, Adds More Sharing Features And Search For Enterprises

dropbox-for-business-use Dropbox, now at 300 million users globally, says that there are 4 million businesses today using its cloud-based platform to store, distribute and share documents. But of those, only around 80,000 have opted so far to use Dropbox for Business, the company’s premium enterprise tier launched earlier this year. Today, the startup is making a move to sweeten the deal, unveiling a host of… Read More

Jul
23
2014
--

Why TokuDB hates Transparent HugePages

If you try to install the TokuDB storage engine on a modern Linux distribution it might fail with following error message:

2014-07-17 19:02:55 13865 [ERROR] TokuDB will not run with transparent huge pages enabled. /> 2014-07-17 19:02:55 13865 [ERROR] Please disable them to continue. /> 2014-07-17 19:02:55 13865 [ERROR] (echo never > /sys/kernel/mm/transparent_hugepage/enabled)

You might be curious why TokuDB refuses to start with Transparent HugePages. Are they not a good thing… allowing smaller kernel page tables and less TLB misses when accessing data in the buffer pool? I was curious, so I asked Tim Callaghan this very question.

This problem originates with TokuDB using jemalloc memory allocator, which uses a particular trick to deal with memory fragmentation. The classical problem with memory allocators is fragmentation – if you allocated a say 2MB chunk from the operating system (typically using mmap),  as the process runs it is likely some of that 2MB memory block will become free but not all of it, hence it can’t be given back to operating system completely. jemalloc uses a clever trick being able to give back portions of memory allocated in such a way through madvise(…, MADV_DONTNEED) call.

Now what happens when you use transparent huge pages? In this case the operating system (and CPU, really) works with pages of a much larger size which only can be unmapped from the address space in its entirety – which does not work when smaller objects are freed which produce smaller free “holes.”

As a result, without being able to free memory efficiently the amount of allocated memory may grow unbound until the process starts to swap out – and in the end being killed by “out of memory” killer at least under some workloads. This is not a behavior you want to see from the database server. As such requiring to disable huge pages is a better choice.

Having said that this is pretty crude requirement/solution – disabling huge pages on complete operating system image to make one application work while others might be negatively impacted. I hope with a future jemalloc version/kernel releases there will be solution where jemalloc simply prevents huge pages usage for its allocations.

Using jmalloc and its approach to remove pages from resident space also makes TokuDB a lot different than typical MySQL instances running Innodb from the process space. With Innodb VSZ and RSS are often close. In fact we often monitor VSZ to ensure it is not excessively large to avoid danger of process starting to swap actively or be killed with OOM killer. TokuDB however often can look like this

[root@smt1 mysql]# ps aux | grep mysqld /> mysql 14604 21.8 50.6 12922416 4083016 pts/0 Sl Jul17 1453:27 /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –plugin-dir=/usr/lib64/mysql/plugin –user=mysql –log-error=/var/lib/mysql/smt1.pz.percona.com.err –pid-file=/var/lib/mysql/smt1.pz.percona.com.pid /> root 28937 0.0 0.0 103244 852 pts/2 S+ 10:38 0:00 grep mysqld

In this case TokuDB is run with defaults on 8GB system – it takes approximately 50% of memory in terms of RSS size, however the VSZ of the process is over 12GB – this is a lot more than memory available.

This is completely fine for TokuDB. If I would not have Transparent HugePages disabled, though, my RSS would be a lot closer to VSZ causing intense swapping or even process killed by OOM killer.

In addition to explaining this to me, Tim Callaghan was also kind enough to share some links on this issue from other companies such as rel="nofollow" href="https://blogs.oracle.com/linux/entry/performance_issues_with_transparent_huge" rel="nofollow">Oracle, rel="nofollow" href="http://dev.nuodb.com/techblog/linux-transparent-huge-pages-jemalloc-and-nuodb" rel="nofollow">NuoDB , rel="nofollow" href="http://answers.splunk.com/answers/112305/on-rh-6-and-splunk-6-my-searches-are-consuming-lots-of-cpu" rel="nofollow">Splunk, rel="nofollow" href="http://www.stechno.net/sap-notes.html?view=sapnote&id=1871318" rel="nofollow">SAP, rel="nofollow" href="http://scn.sap.com/people/markmumy/blog/2014/05/22/sap-iq-and-linux-hugepagestransparent-hugepages" rel="nofollow">SAP(2), which provide more background information on this topic.

The post rel="nofollow" href="http://www.mysqlperformanceblog.com/2014/07/23/why-tokudb-hates-transparent-hugepages/">Why TokuDB hates Transparent HugePages appeared first on rel="nofollow" href="http://www.mysqlperformanceblog.com/">MySQL Performance Blog.

Jul
22
2014
--

PayPal Expands Its Working Capital Service To UK, Switches From Loans To Cash Advances

Screen Shot 2014-07-23 at 01.19.14 As payments platforms look for more ways to grow their margins and usage among businesses, they continue to push into a wider and deeper range of financial services. In one of the latest moves, eBay’s PayPal is expanding its Working Capital service to the UK. This is its first market for PayPal’s lending platform outside of the U.S., where it first launched the service in… Read More

Jul
22
2014
--

Reference architecture for a write-intensive MySQL deployment

We designed href="https://cloud.percona.com/">Percona Cloud Tools (both hardware and software setup) to handle a very high-intensive MySQL write workload. For example, we already observe inserts of 1bln+ datapoints per day. So I wanted to share what kind of hardware we use to achieve this result.

Let me describe what we use, and later I will explain why.

Server:

  • Chassis: Supermicro SC825TQ-R740LPB 2U Rackmount Chassis
  • Motherboard: Supermicro X9DRI-F dual socket
  • CPU: Dual Intel Xeon Ivy Bridge E5-2643v2 (6x 3.5Ghz cores, 12x HT cores, 25M L3)
  • Memory: 256GB (16x 16GB 256-bit quad-channel) ECC registered DDR3-1600
  • Raid: LSI MegaRAID 9260-4i 4-port 6G/s hardware RAID controller, 512M buffer
  • MainStorage: PCIe SSD HGST FlashMAX II 4.8TB
  • Secondary Storage (OS, logs): RAID 1 over 2x 3TB hard drives

Software:

  • OS: Ubuntu 12.04 LTS
  • MySQL: href="http://www.percona.com/software/percona-server" >Percona Server 5.6.19 + TokuDB
  • Backup: LVM partitions + mylvmbackup

When selecting hardware for your application, you need to look at many aspects – typically you’re looking for a solution for which you already have experience in working with and has also proved to be the most efficient option. For us it has been as follows:

Cloud vs Bare Metal /> We have experience having hardware hosted at the data center as well as cash for upfront investments in hardware so we decided to go for physical self-hosted hardware instead of the cloud. Going this route also gave us maximum flexibility in choosing a hardware setup that was the most optimal for our application rather than selecting one of the stock options.

Scale Up vs Scale Out /> We have designed a system from scratch to be able to utilize multiple servers through sharding – so our main concern is choosing the most optimal configuration for the server and provisioning servers as needed. In addition to raw performance we also need to consider power usage and overhead of managing many servers which typically makes having slightly more high-end hardware worth it.

Resource Usage /> Every application uses resources in different ways so an optimal configuration will be different depending on your application. Yet all applications use the same resources you need to consider. Typically you want to plan for all of your resources to be substantially used – providing some margin for spikes and maintenance.

CPU

  • Our application processes a lot of data and uses the TokuDB storage engine which uses a lot of CPU for compression, so we needed powerful CPUs.
  • Many MySQL functions are not parallel, think executing single query or Alter table so we’re going for CPU with faster cores rather than larger amount of cores. The resulting configuration with 2 sockets giving 12 cores and 24 threads is good enough for our workloads.
  • Lower end CPUs such as Xeon E3 have very attractive price/performance but only support 32GB of memory which was not enough for our application.

Memory

  • For database boxes memory is mainly used as a cache, so depending on your application you may be better off investing in memory or storage for optimal performance. Check out href="http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/" >this blog post for more details.
  • Accessing data in memory is much faster than even on the fastest flash storage so it is still important. /> For our workload having recent data in memory is very important so we get as much “cheap” memory as we can populating all 16 slots with 16GB dimms which have attractive cost per GB at this point.

Storage /> There are multiple uses for the storage so there are many variables to consider

  • Bandwidth
    • We need to be able access data on the storage device quickly and with stable response time. HGST FlashMax II has been able to meet these very demanding needs.
  • Endurance
    • When using flash storage you need to worry about endurance – how much beating with writes flash storage can handle before it wears out. Some low cost MLC SSDs would wear out in the time frame of weeks if being written with maximum speed. HGST FlashMax II has endurance rating of 10 Petabytes written (for a random workload) – 30 Petabytes written (for a sequential workload)
    • We also use TokuDB storage engine which significantly reduces amount of writes compared to Innodb.
  • Durability
    • Does the storage provide true durability with data guaranteed to be persisted when write is acknowledged at the operating system level when power goes down or is loss possible? /> We do not want to risk database corruption in case of power failure so we were looking for storage solution which guarantees durability. /> HGST FlashMax II guarantees durability which has been confirmed by our stress tests.
  • Size
    • To scale application storage demands you need to scale both number of IO operations storage can handle and storage size. For flash storage it is often the size which becomes limiting factor. /> HGST FlashMax II 4.8 TB capacity is best available on the market which allows us to go “All Flash” and achieve very quick data access to all our data set.
  • Secondary Storage
    • Not every application need requires flash storage properties.
    • We have secondary storage with conventional drives for operating system and logs. /> Sequential read/write pattern works well with low cost conventional drives and also allow us to increase flash life time, having it handling less writes.
    • We’re using RAID with BBU for secondary storage to be able to have fully durable binary logs without paying high performance penalty.

Why PCIe SSD over SATA SSD? /> There are arguments that SATA SSD provides just a good enough performance for MySQL and there is no need for PCIe. While these arguments are valid in one dimension, there are several more to consider.

First, like I said PCIe SSD still provides a best absolute response time and it is an important factor for an end user experience in SaaS systems like href="https://cloud.percona.com/">Percona Cloud Tools. /> Second, consider maintenance operations like backup, ALTER TABLES or slave setups. While these operations are boring and do not get as much attention as a response time or throughput in benchmarks, it is still operations that DBAs performs basically daily, and it is very important to finish a backup or ALTER TABLE in a predictable time, especially on 3-4TB datasize range. And this is where PCIe SSD performs much better than SATA SSDs. For SATA SSD, especially bigger size, write endurance is another point of concern.

Why TokuDB engine? /> The TokuDB engine is the best when it comes to insert operations to a huge dataset, and few more factors makes it a no-brainer:

  • TokuDB compression is a huge win. I estimate into this storage ( FlashMAX II 4.8TB) we will fit about 20-30TB of raw data.
  • TokuDB is SSD friendly, as it performs much less data writes per INSERT operation than InnoDB, which greatly extends SSD (which is, well, expensive to say the least) lifetime.

The post rel="nofollow" href="http://www.mysqlperformanceblog.com/2014/07/22/reference-architecture-for-a-write-intensive-mysql-deployment/">Reference architecture for a write-intensive MySQL deployment appeared first on rel="nofollow" href="http://www.mysqlperformanceblog.com/">MySQL Performance Blog.

Jul
21
2014
--

Another Screen Shot Of The Upcoming Windows Start Menu Leaks

thing (1) Another week, another leak. Today we have a new, purported screenshot of the upcoming return of the Start Menu to Windows. Read More

Jul
21
2014
--

Percona XtraDB Cluster 5.6.19-25.6 is now available

href="http://www.mysqlperformanceblog.com/wp-content/uploads/2013/02/XtraDB-Cluster.jpg"> class="alignright size-full wp-image-12836" src="http://www.mysqlperformanceblog.com/wp-content/uploads/2013/02/XtraDB-Cluster.jpg" alt="Percona XtraDB Cluster 5.6.19-25.6" 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 July 21st 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. We’re also happy to announce that Ubuntu 14.04 LTS users can now download, install, and upgrade Percona XtraDB Cluster 5.6 from title="Percona XtraDB Cluster 5.6 software repository" href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/installation.html#using-percona-software-repositories?id=repositories:start" >Percona’s software repositories.

Based on Percona Server href="http://www.percona.com/doc/percona-server/5.6/release-notes/Percona-Server-5.6.19-67.0.html">5.6.19-67.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.6, and on rel="nofollow" href="https://launchpad.net/wsrep-group/+milestone/5.6.19-25.6" rel="nofollow">Codership wsrep API 25.6, Percona XtraDB Cluster 5.6.19-25.6 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.19-25.6" rel="nofollow">5.6.19-25.6 milestone at Launchpad.

New Features:

  • Percona XtraDB Cluster now supports storing the Primary Component state to disk by setting the href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#pc.recovery">pc.recovery variable to true. The Primary Component can then recover automatically when all nodes that were part of the last saved state reestablish communications with each other. This feature can be used for automatic recovery from full cluster crashes, such as in the case of a data center power outage and graceful full cluster restarts without the need for explicitly bootstrapping a new Primary Component.
  • When joining the cluster, the state message exchange provides us with gcache seqno limits. That information is now used to choose a donor through IST first, and, if this is not possible, only then SST is attempted. The  href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_sst_donor">wsrep_sst_donor setting is honored, though, and it is also segment aware.
  • An asynchronous replication slave thread was stopped when the node tried to apply the next replication event while the node was in non-primary state. But it would then remain stopped after the node successfully re-joined the cluster. A new variable,  href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_restart_slave">wsrep_restart_slave, has been implemented which controls if the MySQL slave should be restarted automatically when the node re-joins the cluster.
  • Handling install message and install state message processing has been improved to make group forming a more stable process in cases when many nodes are joining the cluster.
  • A new href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-status-index.html#wsrep_evs_repl_latency">wsrep_evs_repl_latency status variable has been implemented which provides the group communication replication latency information.
  • Node consistency issues with foreign key grammar have been fixed. This fix introduces two new variables: href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_slave_FK_checks">wsrep_slave_FK_checks and href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_slave_UK_checks">wsrep_slave_UK_checks. These variables are set to TRUE and FALSE respectively by default. They control whether Foreign Key and Unique Key checking is done for applier threads.

Bugs Fixed:

  • Fixed the race condition in Foreign Key processing that could cause assertion. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1342959" rel="nofollow">#1342959.
  • The restart sequence in scripts/mysql.server would fail to capture and return if the start call failed to start the server. As a result, a restart could occur that failed upon start-up, and the script would still return 0 as if it worked without any issues. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1339894" rel="nofollow">#1339894.
  • Updating a unique key value could cause the server to hang if a slave node had enabled parallel slaves. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1280896" rel="nofollow">#1280896.
  • Percona XtraDB Cluster has implemented threadpool scheduling fixes. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1333348" rel="nofollow">#1333348.
  • garbd was returning an incorrect return code, ie. when garbd was already started, return code was 0. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1308103" rel="nofollow">#1308103.
  • rsync SST would silently fail on joiner when the rsync server port was already taken. Bug fixed href="http://www.mysqlperformanceblog.com/2014/07/21/percona-xtradb-cluster-5-6-19-25-6-now-available/wsrep_sst_rsync%20would%20silently%20fail%20on%20joiner%20when%20rsync%20server%20port%20was%20already%20taken.%20Bug%20fixed%20#1099783.">#1099783.
  • When href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#gmcast.listen_addr">gmcast.listen_addr was configured to a certain address, the local connection point for outgoing connections was not bound to the listen address. This would happen if the OS has multiple interfaces with IP addresses in the same subnet. The OS would pick the wrong IP for a local connection point and other nodes would see connections originating from an IP address which was not listened to. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1240964" rel="nofollow">#1240964.
  • An issue with re-setting galera provider (in href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-system-index.html#wsrep_provider_options">wsrep_provider_options) has been fixed. Bug fixed #1260283.
  • Variable wsrep_provider_options couldn’t be set in runtime if no provider was loaded. Bug fixed #1260290.
  • Percona XtraDB Cluster couldn’t be built with Bison 3.0. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1262439" rel="nofollow">#1262439.
  • MySQL wasn’t handling exceeding the max writeset size wsrep error correctly. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1270920" rel="nofollow">#1270920.
  • Fixed the issue which caused a node to hang/fail when SELECTs/SHOW STATUS was run after FLUSH TABLES WITH READ LOCK was used on a node with wsrep_causal_reads set to 1 while there was a DML on other nodes. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1271177" rel="nofollow">#1271177.
  • Lowest group communication layer (evs) would fail to handle the situation properly when a large number of nodes would suddenly start recognizing each other. Bugs fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1271918" rel="nofollow">#1271918 and rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1249805" rel="nofollow">#1249805.
  • Percona XtraBackup SST would fail if the progress option was used with a large number of files. Bug fixed rel="nofollow" href="https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1294431" rel="nofollow">#1294431.

NOTE: When performing an upgrade from an older 5.6 version on Debian/Ubuntu systems, in order to upgrade the Galera package correctly, you’ll need to href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/installation/apt_repo.html#apt-pinning-the-packages">pin the Percona repository and run: apt-get install percona-xtradb-cluster-56. This is required because older Galera deb packages have an incorrect version number. The correct href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-status-index.html#wsrep_provider_version">wsrep_provider_version after upgrade should be 3.6(r3a949e6).

This release contains 50 fixed bugs. The complete list of fixed bugs can be found in our href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/release-notes/Percona-XtraDB-Cluster-5.6.19-25.6.html">release notes.

Release notes for Percona XtraDB Cluster href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/release-notes/Percona-XtraDB-Cluster-5.6.19-25.6.html">5.6.19-25.6 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!

Percona XtraDB Cluster href="http://www.percona.com/doc/percona-xtradb-cluster/5.6/errata.html">Errata can be found in our documentation.

The post rel="nofollow" href="http://www.mysqlperformanceblog.com/2014/07/21/percona-xtradb-cluster-5-6-19-25-6-now-available/">Percona XtraDB Cluster 5.6.19-25.6 is now available appeared first on rel="nofollow" href="http://www.mysqlperformanceblog.com/">MySQL Performance Blog.

Jul
21
2014
--

Digital Hints Point Towards More Unified Windows Experience

Screen Shot 2014-07-21 at 8.38.51 AM A job posting and a LinkedIn page are driving conversation in the Microsoft-watching community this morning. The job listing details a position on the “XAML team [...] building the UI framework at the core of the ‘One Microsoft’ OS.” The goal of that team is to “[enable] developers to create UI that works well across all of [Microsoft's] devices: phones,… Read More

Jul
21
2014
--

Percona Monitoring Plugins 1.1.4 release

Percona is glad to announce the release of href="http://www.percona.com/software/percona-monitoring-plugins/" >Percona Monitoring Plugins 1.1.4.

Changelog:

* Added login-path support to Nagios plugins with MySQL client 5.6 (bug 1338549) /> * Added a new threshold option for delayed slaves to pmp-check-mysql-replication-delay (bug 1318280) /> * Added delayed slave support to pmp-check-mysql-replication-running (bug 1332082) /> * Updated Nagios plugins and Cacti script to leverage lock-free SHOW SLAVE STATUS in Percona Server (bug 1297442) /> * Fixed pmp-check-mysql-replication-delay integer-float issue with MariaDB and MySQL 5.6 (bugs 1245934, 1295795) /> * ss_get_rds_stats.py was not installed with 755 permissions from the package (bug 1316943) /> * Cacti MySQL template item “handler_savepoint_rollback” was GAUGE type instead of DERIVE (bug 1334173) /> * Fixed Zabbix running-slave check issue on some Debian systems (bug 1310723)

A new tarball is available from href="http://www.percona.com/downloads/percona-monitoring-plugins/" >downloads area or RPM and DEB packages from our href="http://www.percona.com/software/repositories" >software repositories. The plugins are fully supported for customers with a href="http://www.percona.com/mysql-support/" >Percona Support contract and free installation services are provided as part of some contracts. In addition as part of href="http://www.percona.com/products/mysql-remote-dba" >Percona’s Remote DBA installation and setup of these tools are included with our services. You can find links to the documentation, href="http://www.percona.com/forums/questions-discussions/percona-monitoring-plugins" >forums and more at the href="http://www.percona.com/software/percona-monitoring-plugins/" >project homepage.

class="alignleft size-full wp-image-19964" alt="Percona Monitoring Plugins" src="http://www.mysqlperformanceblog.com/wp-content/uploads/2013/12/Percona-Monitoring-Plugins.jpg" width="251" height="83" style="margin-bottom: 40px"/>About Percona Monitoring Plugins /> href="http://www.percona.com/software/percona-monitoring-plugins" >Percona Monitoring Plugins are high-quality components to add enterprise-grade MySQL monitoring and graphing capabilities to your existing in-house, on-premises monitoring solutions. The components are designed to integrate seamlessly with widely deployed solutions such as Nagios, Cacti and Zabbix and are delivered in the form of templates, plugins, and scripts which make it easy to monitor MySQL performance.

The post rel="nofollow" href="http://www.mysqlperformanceblog.com/2014/07/21/percona-monitoring-plugins-1-1-4-release/">Percona Monitoring Plugins 1.1.4 release appeared first on rel="nofollow" href="http://www.mysqlperformanceblog.com/">MySQL Performance Blog.

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