Containers like Docker and Rocket are getting more popular every
day. In my conversations with customers, they consistently
ask what containers are and how they can use them in their
environment. If you’re as curious as most people, read on. . .

How did this happen?

From what I understand, containers grew out of Google’s (and
others’) need for massive horizontal scale. Now, this is hardly a
unique problem. At the time there were several different
solutions out there that could help deploy and orchestrate
the applications and infrastructure necessary to scale — namely
virtual machines (VMs) and their orchestration services (like
Vmware’s vCenter). At the uber-massive scale that companies like
Google were pushing, however, server virtualization had some
serious drawbacks. Enter containers. . .

Over the last year, the Ceph world drew me in.
Partly because of my taste for distributed systems, but also
because I think Ceph represents a great opportunity for MySQL
specifically and databases in general. The shift from local
storage to distributed storage is similar to the shift from bare
disks host configuration to LVM-managed disks configuration.

Most of the work I’ve done with Ceph was in collaboration with
folks from Red Hat (mainly Brent Compton and Kyle Bader). This
work resulted in a number of talks presented at the Percona Live conference in April and the
Red Hat
Summit San Francisco at the end of June. I could write a lot
about using Ceph with databases, and I hope this post …

Introduction
In my last blog post, Internet of Things, Messaging and MySQL, I
have showed how to start your own Internet of Things with
Particle Photon board. That implementation is great, but requires
constant internet (wi-fi) access as the Particle Photon board
does not have any local storage. If you do not have a reliable
network access (i.e. in some remote places) or need something
really small to store your data you can now use Intel Edison. I’ve even install MySQL on
Edison, which makes it the smallest (in size) MySQL server in the
world! Other options include:

Thank you for attending my July 15 webinar,
“Creating Best in Class Backup solutions for your MySQL
environment.” Due to the amount of content we discussed and some
minor technical difficulties faced near the end of webinar we
have decided to cover the final two slides of the presentation
along with the questions asked by attendees during the webinar
via this blog post.

The slides are available for download. And you can
watch the webinar in it’s entirety here.

In a post, written a few months ago, I found that
using EXT4 transactions with the “data=journal” mount option,
improves the write performance significantly, by 55%, without
putting data at risk. Many people commented on the post
mentioning they were not able to reproduce the results and thus,
I decided to further investigate in order to find out why my
results were different.

So, I ran sysbench benchmarks on a few servers and found when the
InnoDB double-write buffer limitations occur and when they don’t.
I also made sure some of my colleagues were able to reproduce the
results. Basically, in order to reproduce the results you need
the following conditions:

During April’s Percona Live MySQL Conference and Expo 2014, I
attended a talk on MySQL 5.7 performance an scalability
given by Dimitri Kravtchuk, the Oracle MySQL benchmark
specialist. He mentioned at some point that the InnoDB double
write buffer was a real performance killer. For the ones that
don’t know what the innodb double write buffer is, it is a disk
buffer were pages are written before being written to the actual
data file. Upon restart, pages in the double write buffer are
rewritten to their data files if complete. This is to avoid data
file corruption with half written pages. I knew it has an impact
on performance, on ZFS since it is transactional I always disable
it, but I never realized how important the performance impact
could be. Back from PLMCE, a friend had dropped home a Dell R320
server, asking …

The submissions are far ranging and cover some really interesting
topics, making the lineup for Percona Live London really strong!
What the committee looks for in a submission is how much “value”
a talk will bring to the conference – this is to say it needs to
be far more that a product demo. As such, real-world
experiences are receiving much more favorable reviews, along with
talks that cover methodologies the attendees will …

The new Percona Server 5.6 is the most manageable, highest
performance, and most scalable version of MySQL available.
Percona Server 5.6 is the best open source MySQL choice for
enterprise-grade applications because it combines new features
with the best features of Percona Server 5.5 and MySQL 5.6 to
provide unparalleled performance.

For the same customer I am exploring ZFS for backups, the twin
server is using regular LVM and XFS. On this twin, I have setup
mylvmbackup for a more conservative backup approach. I quickly
found some odd behaviors, the backup was taking much longer than
what I was expecting. It is not the first time I saw that, but
here it was obvious. So I recorded some metrics, bi from
vmstat and percent of cow space used from lvs during a backup.
Cow space is the Copy On Write buffer used by LVM to record the
modified pages like they were at the beginning of the snapshot.
Upon reads, LVM must scan the list to verify that there’s no
newer version. Here’s the other details about the backup:

I am currently working with a large customer
and I am involved with servers located in two data centers, one
with Solaris servers and the other one with Linux servers. The
Solaris side is cleverly setup using zones and ZFS and this
provides a very low virtualization overhead. I learned quite a
lot about these technologies while looking at this, thanks to
Corey Mosher.

On the Linux side, we recently deployed a pair on servers for
backup purpose, boxes with 64 300GB SAS drives, 3 raid
controllers and 192GB of RAM. These servers will run a few slave
instances each of production database servers and will perform
the backups. The write load is not excessive so a single
server can easily handle the write load of all the MySQL
instances. The original idea was to configure them with
raid-10 + LVM, making sure to …

Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.