PlanetMysql.ru — информация о СУБД MySQL

XtraBackup is a great piece of software from Percona, which allows creating (nearly) lock-less MySQL/InnoDB backups. The tool has been around for quite some time and recently even received a major version bump. I have relied on it many times over the years. As it turns out, using it in some configurations may lead to heavy swapping or prevent MySQL from running queries.

So far I only kept complaining about the wrapper script XtraBackup has been distributed with and which was taken from Oracle’s InnoDB Hot Backup. The infamous innobackupex-1.5.1 was neither well written, nor was it even fully compatible with the XtraBackup’s feature set. This sometimes led to weird problems where there should not be any.

This time the problem can appear elsewhere. Mostly when one using the tool does not understand how it works in certain circumstances.

How does XtraBackup work?

In a few short words. XtraBackup performs two major tasks while it is running. The primary task is of course copying tablespaces, which constitutes the core of each backup. Because the process isn’t anything like making a point-in-time snapshot, it takes a significant amount of time as InnoDB files are sequentially read and written into another location one after another. There will always be transactions changing data in tables between when a backup started and when it ended. So in order to provide a fully consistent, point-in-time backup, XtraBackup has to work on another task. It follows and archives InnoDB transaction logs contents as new transactions commit while the process is running. The end result is an inconsistent backup of tablespaces and a transaction log that enables XtraBackup to fix the inconsistencies during prepare phase.

Streaming mode.

In many cases XtraBackup is used in streaming mode. It enables sending a backup straight over a network link into another system without storing any of the files on a database server itself. This is very useful for larger databases which may simply not fit two complete copies of data on available storage. It may be also useful for busy databases as it removes many disk I/Os that would otherwise be used for writing an archive to local disks.

However it is not entirely true that a streaming backup does not use any disk space on the source server:

–tmpdir=DIRECTORY
This option specifies the location where a temporary file will be stored. The option accepts a string argument. It should be used when –remote-host or –stream is specified. For these options, the transaction log will first be stored to a temporary file, before streaming or copying to a remote host. This option specifies the location where that temporary file will be stored. If the option is not specifed, the default is to use the value of tmpdir read from the server configuration.

A transaction log backup will always be written to the local storage first, even if it has to be shipped out elsewhere later.

The problem.

What if you want to run XtraBackup, but also have configured database to use memory-based storage for temporary space, e.g. tmpdir in my.cnf was set to /dev/shm or other location that mounts a tmpfs volume? Such configuration is often used to help performance when a lot of temporary tables are being created on disk. Assuming that you fail to notice the tmpdir option comment for XtraBackup, which is not actually very unlikely as I have seen very few people use it, you will be running a backup that by default (temporarily) archives the database transaction log into RAM.

If the option is not specifed, the default is to use the value of tmpdir read from the (MySQL) server configuration.

Given your database is sufficiently large and busy, or perhaps because you throttle XtraBackup, the backup process may run many hours. In several hours time the transaction logs can grow a lot, even by several gigabytes or more. By default a tmpfs volume that is these days automatically mounted by any Linux distribution can use up to 50% of RAM. As in practice no one really changes the limit from its default value, the transaction log archive can possibly also eat up to 50% of system’s memory. If RAM utilization on a server was high, and usually a mature database system uses even more than 90% of the available memory, it could eventually end up like this:

Swapping. When it happens a database server that is under any real load essentially stops responding. In this case it may not even matter whether it is MySQL instance memory being paged out or perhaps tmpfs volume contents.

At the same time the memory volume contents would look like this:

garfield ~ # ls -lh /dev/shm/
-rw-r--r--  1 root root   75 05-22 09:08 mysql-stderr
-rw-r--r--  1 root root  226 05-22 09:08 mysql-stdout
-rw-r--r--  1 root root   2G 05-22 09:08 xtrabackup_logfile

More problems.

The above does not have to be the only problem. Regardless of what MySQL uses for its temporary directory, if the storage is too small (e.g. some use a few gigabytes large /tmp partition), more bad things can happen.

If it gets full during backup, MySQL will not be able to run any queries that rely on temporary files, e.g. some that use GROUP BY or ORDER BY:

mysql> SELECT * FROM sbtest ORDER BY pad DESC LIMIT 5;
ERROR 3 (HY000): Error writing file '/dev/shm/MYJee0PR' (Errcode: 28)
mysql> Bye
garfield ~ # perror 28
OS error code  28:  No space left on device

Another problem that I spotted was that XtraBackup continued performing backup even after it noticed and reported that one of its writes failed. This is clearly a bug, which permits creation of a broken backup.

innobackupex-1.5.1: Backing up file '/var/lib/mysql/sbtest/sbtest.ibd'
>> log scanned up to (1 4052543506)
>> log scanned up to (1 4052543506)
>> log scanned up to (1 4052543506)
write: 65536 > 2048
xtrabackup: Error: write to stdout
xtrabackup: Error: xtrabackup_copy_logfile() failed.
innobackupex-1.5.1: Backing up file '/var/lib/mysql/sbtest/sbtest2.ibd'
[..]
xtrabackup: The latest check point (for incremental): '1:4115657100'
xtrabackup: Error: log_copying_thread failed.
120522 13:16:19  innobackupex-1.5.1: All tables unlocked
120522 13:16:19  innobackupex-1.5.1: Connection to database server closed

innobackupex-1.5.1: Backup created in directory '/root/backup'
innobackupex-1.5.1: MySQL binlog position: filename 'mysqld-bin.000067', position 107090
120522 13:16:19  innobackupex-1.5.1: completed OK!
innobackupex-1.5.1: You must use -i (--ignore-zeros) option for extraction of the tar stream.
garfield backup # echo $?
0

Conclusions.

Be careful when implementing streaming backup with XtraBackup. Make sure to check where it will store its temporary files as they may grow relatively large or even better always explicitly set tmpdir in the command line.

This problem also raises another important matter. If you configure a MySQL server to use a RAM based volume for a database temporary storage, make sure to tune tmpfs volume configuration rather than leave it with the default limit of 50%.

PlanetMySQL Voting: Vote UP / Vote DOWN

You have been told (guilty as charged), that the only way to get rid of the huge InnoDB tablespace file (commonly named ibdata1), when moving to innodb_file_per_table, is to do a logical dump of your data, completely erase everything, then import the dump.

To quickly reiterate, you can only delete the ibdata1 file when no InnoDB tables exist. Delete this file with an existing InnoDB table, even a table in its own tablespace, and nothing ever works anymore.

The problem with the dump-based solution

The impact of doing a logical dump is often overwhelming. Well, the dump may be tolerable, but the restore is much longer. The real pain is that you can't do this one table at a time: you have to destroy everything before dropping the ibdata1 file; you then have to import everything.

Perhaps the most common scenario is that we do the changes on a slave, so as not to completely shut down our database. This is nice; no one is aware of the shutdown process. However, Huston, we have a problem: we need to make sure we can keep up the binary logs on the master for the duration of the entire process.

A semi-solution for binary logs

You may get by by keeping the SQL_IO_THREAD running on the slave while dump is taken (SQL thread is better turned off). If you're careful, you could do the same after restarting the database: you should still be able to acquire relay logs. With row based replication becoming more common, the problem of binary logs disk space returns: the logs (rather, log entries) are just so much larger!

Either way, the process can takes long days, at the end of which your slave is up, but lags for long days behind.

Wishful thought: do it one table at a time

If we could do it one table at a time, and assuming our dataset is fairly split among several tables (i.e. not all of our 500GB of data is in one huge table), life would be easier: we could work on a single table, resume replication, let the slave catch up, then do the same for the next table.

How? Didn't we just say one can only drop the ibdata1 file when no InnoDB tables exist?

Solution: do it one table at a time

I'm going to illustrate what seems like a longer procedure. I will later show why it is not, in fact, longer.

The idea is to first convert all your tables to MyISAM (Yay! A use for MyISAM!). That is, convert your tables one table at a time, using normal ALTER TABLE t ENGINE=MyISAM.

Please let go of the foreign keys issue right now. I will address it later, there's a lot to be addressed.

So, on a slave:

1. STOP SLAVE
2. One ALTER TABLE ... ENGINE=MyISAM
   
3. START SLAVE again
4. Wait for slave catch up
5. GOTO 1

What do we end up with? A MyISAM only database. What do we do with it? Why, convert it back to InnoDB, of course!

But, before that, we:

1. Shut MySQL down
2. Delete ibdata1 file, ib_logfile[01] (i.e. delete all InnoDB files)
3. Start MySQL

A new ibdata1 file, and new transaction log files will be created. Note: the new ibdata1 file is small. Mission almost accomplished.

We then:

1. STOP SLAVE
2. Do one ALTER TABLE ... ENGINE=InnoDB [ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 ...]
   
3. START SLAVE again
4. Wait for slave catch up
5. GOTO 1

What do we end up with? An InnoDB only database, with true file per table, and a small ibdata1 file. Space recovered!

The advantage of this method

The thing is, we resume replication after each table alteration. This means breaking the lag period into many smaller periods. While the total runtime does not reduce, we do reduce the maximum lag time. And this makes for easier recovery: no need to store multitudes of binary logs!

So what about the foreign keys?

Phew. Continued next post.

PlanetMySQL Voting: Vote UP / Vote DOWN

You could say: what could be the reason for having really big number of tables? Just design the application properly! It’s not always that easy. And this post isn’t really about arguing whether having many tables is good or not, it’s about what happens in terms of memory usage if you already reached that point.

Btw what do I mean by *many*? From my experience it’s tens of thousends or even millions rather than hundreds.

The inspiration for me to write this post was strong desire to try out the latest declared improvements in that area announced to be done in MySQL 5.6. _¹

What I did was a very simple test where I loaded sql dump of databases and tables definitions only into different versions of MySQL. During the load time I was monitoring memory usage of mysqld process (RSS value from ps aux) as a function of tables number. Additionaly I compared disk usage in case you choose single innodb table space versus file per table, also in relation to number of tables.

Settings I used for test were all default and I chose lowest possible innodb buffer pool:

innodb_buffer_pool_size = 8M

except when I started to test Percona versions I realized that the lowest allowed value there was 32MB, this warning appeared in error log after the service start:

“[Warning] option ‘innodb-buffer-pool-size’: signed value 8388608 adjusted to 33554432″

So both Percona versions I tested had 32MB and all others had 8MB but I think it wasn’t that important in this particular test.

Additionally for Percona versions I used the

innodb_dict_size_limit

variable introduced already in 2009 _².

The sample table set that I used has around 50 different tables with various number of fields and indexes.

Here are the results of creating more than a million tables:

 

I wonder what is the difference between the patch that Percona did few years ago (and which was available starting from 5.0.77-b13 of Percona Server) and latest fix available in MySQL 5.6.x branch. Any way It’s really nice to see it among all other great improvements that are happening in 5.6.x development line.

OK, now let’s see how the disk usage is affected in this simple test by just creating empty tables in two scenarios: single InnoDB ibdata file and when innodb_file_per_table option is set. In this case I observed no differences between various MySQL versions, so you can see only one here.

Related links:

http://www.mysqlperformanceblog.com/2010/05/06/how-much-memory-innodb-dictionary-can-take/

http://fromdual.com/how-mysql-behaves-with-many-schemata-tables-and-partitions

http://www.percona.com/doc/percona-server/5.5/management/innodb_dict_size_limit.html?id=percona-server:features:innodb_dict_size_limit

http://dev.mysql.com/doc/refman/5.6/en/innodb-performance.html#innodb-performance-table-cache

http://blogs.innodb.com/wp/2011/12/improving-innodb-memory-usage-continued/

http://ma.tt/2006/03/wordpress-and-lyceum/

References:

1. http://blogs.innodb.com/wp/2011/12/improving-innodb-memory-usage/
2. http://www.mysqlperformanceblog.com/2009/02/11/limiting-innodb-data-dictionary/

PlanetMySQL Voting: Vote UP / Vote DOWN

Tackling machine data on the ground to ensure successful operations for NASA in space

Issues addressed:

The Company:  Southwest Research Institute (SwRI) is an independent, nonprofit applied research and development organization. The staff of more than 3,000 specializes in the creation and transfer of technology in engineering and the physical sciences. Currently, SwRI is part of an international team working on the NASA Magnetospheric Multiscale (MMS) mission. MMS is a Solar Terrestrial Probes mission comprising four identically instrumented spacecraft that will use Earth’s magnetosphere as a laboratory to study the microphysics of three fundamental plasma processes: magnetic reconnection, energetic particle acceleration, and turbulence.

The Challenge:  SwRI is responsible for archiving an enormous quantity of data generated by the Hot Plasma Composition Analyzer (HPCA). The device is used to count hydrogen, helium, and oxygen ions in space at different energy levels. These instruments require extensive calibration data and each one is a customized, high precision device that is built, tested, and integrated by hand. SwRI must capture and store all the test and calibration data during the 2-3 week bursts activity that are required for each of the 4 devices.

“During each of these calibration runs, there are several data sources flowing into the server, each one leading to an index in the database,” said Greg Dunn, a Senior Research Engineer at SWRI. “Each packet that arrives gets a timestamp, message type, file name and location associated with it. A second process goes through that data and parses it out – information such as voltage, temperature, pressure, current, ion energy, particle counts, and instrument health must be inserted into the database for every record. This can load the database with up to 400 or 500 inserts per second.”

“Being able to monitor the performance of the instrument and judge the success of the tests and calibrations in near real time is critical to the project,” noted Dunn. “There are limited windows to do testing cycles and make adjustments for any issues that arise. Any significant slip in the testing could cost tens of thousands of dollars and jeopardize the timing of the satellite launch.”

“We started seeing red flags with InnoDB early in the ramp-up phase of the project, as our initial data set hit 400GB,” said Dunn. “Size was the first issue. Each test run was generating around 94 million inserts or around 90GB of data, quickly exceeding the capacity allocated for the program. In addition, as our database grew to 800M records, we saw InnoDB insertion performance drop off to a trickle. Even with modest data streams at 100 records per second, InnoDB was topping out at 45 insertions per second. Being able to monitor these crucial calibration activities in a timely fashion and in a cost effective manner was at risk.”

To keep up with the workload and data set, SwRI considered several options, but they failed to meet program performance and price goals. These included:

Partitioning / Separate Databases – “We considered partitioning, but this can be a challenge to set up and it introduces additional complexity,” said Dunn. “We also looked at putting each calibration into its own database, but that would have made it much more difficult to correlate across different databases.”

Additional RAM – “Increasing the available RAM from 12 GB up to 100 GB was not enough by itself,” claimed Dunn. “We briefly considered keeping everything in RAM, but that was not a realistic or efficient way to address a data set size that was promising to grow to several terabytes by the end of the program.”

The Solution:  Once TokuDB was installed, SwRI’s big data management headache quickly subsided. “The impact to our required storage was dramatic,” noted Dunn. “We benefited from over 9x compression. In our comparison benchmarks, we went from 452GB with InnoDB to 49GB with TokuDB.”

There was also a dramatic improvement in performance. “Suddenly, we no longer had to struggle to keep up with hundreds of insertions per second,” stated Dunn. “Our research staff could immediately see whether or not the experiment was running correctly and whether the test chamber was being used effectively. We didn’t have to worry that insufficient data analysis horsepower might lead to downstream schedule delays.”

The Benefits: 

Cost Savings: “The hardware savings were impressive,” noted Dunn. “With InnoDB, going to larger servers, adding 100s of GBs of additional RAM along with many additional drives would have easily cost $20,000 or more, and still would not have addressed all our needs. TokuDB was by far both a cheaper and simpler solution.”

Hot Column Addition: “As we continue to build out the system and retool the experiments, flexibility in schema remains important,” stated Dunn. “TokuDB’s capability to quickly add columns of data is a good match for our environment, where our facility is still evolving and sometimes has new sensors or monitors installed that need to be added to existing large tables.”

Fast Loader: “The open source toolset that Tokutek designed to parallelize the loading of the database was very helpful,” said Dunn.  “We were able to bring down the load of the database from MySQL dump backup from 30 hours to 7 hours.”

PlanetMySQL Voting: Vote UP / Vote DOWN

Being a data recovery specialist and having recovered countless GBs of corrupted, and/or stranded, InnoDB data in my days, I am very happy to hear about the new InnoDB Transportable Tablespaces coming in MySQL 5.6!

Back in the day, if you had a stranded .ibd file (the individual InnoDB data file with –innodb-file-per-table option), you basically had nothing (even though that file contained all of the data). This was because unless you had the original instance that that particular .ibd file (table) originated from, there was no way to load it, import, or dump from it. So it was not of much use, though all the data was *right* there.

Thus I created the method of Recovering an InnoDB table from only an .ibd file (I should note that this was before the InnoDB Recovery Tool had been released, which can also be used to recover data from a stranded .ibd file too).

However, if you’ve used either my method or the InnoDB Recovery Tool for such a job, it can be a bit of work to get the data dumped. For those experienced, it goes much faster. But still, you cannot get any faster than just being able to (roughly) import the individual tablespace right into any running MySQL 5.6 instance.

Nice work!

Note: Again, I must mention this is only in MySQL 5.6, so if you have a stranded .ibd file you need to recover data from pre-5.6, you’ll either need to use my method or the InnoDB Recovery Tool.

 

PlanetMySQL Voting: Vote UP / Vote DOWN

There are a few ways to implement counters. Even though it’s not a complex feature, often I see people having problems around it. This post describes how bad implementation can impact both application and MySQL performance and how to improve it.

A customer asked me for help with performance problem they were facing. I logged into their database and found many client connections waiting for table locks. Almost all threads were stuck on one, small table called hits. What was the reason?

The problem was related to the way they developed a very simple system for counting page views they later used in some reporting. The table structure was:

mysql> SHOW CREATE TABLE hits\G
*************************** 1. row ***************************
Table: hits
Create Table: CREATE TABLE `hits` (
`cnt` int(11) NOT NULL
) ENGINE=MyISAM

mysql> SELECT * FROM hits;
+---------+
| cnt     |
+---------+
| 3823273 |
+---------+

The application was updating cnt column on every page load, or sometimes even multiple times per page load (although that was actually a bug), with such obvious query:
UPDATE hits SET cnt = cnt + 1;

It may not scale with traffic. MyISAM storage engine uses table level locking, which means that every UPDATE sets an exclusive lock on the table and forces any other threads accessing the same table concurrently to wait for the lock to be released. When traffic peaks beyond certain threshold, the cascade of locks may simply prevent the application from working at all. This is what happened to the customer during a traffic spike coming from some marketing campaign they launched.

Switching to InnoDB may seem like a natural choice, but does it really help here? Not so much. At the very least, it may not be enough.

InnoDB implements row-level locking mechanism which is better as locks are set on smaller chunks of data – individual records rather than entire tables. It means that concurrent queries updating different rows in the same table would not block each other, unlike in MyISAM. However, the table contains only one row, so that particular advantage does really exist there.

When row-level locking might become a bottleneck, why not just use more rows that could be updated instead of just one?

CREATE TABLE `hits` (
`id` tinyint(4) NOT NULL,
`cnt` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB

This enables multiple counters, each of which can be incremented independently of others, and what’s more important also concurrently.

mysql> SELECT * FROM hits;
+------+------+
| id   | cnt  |
+------+------+
|    1 |   10 |
|    2 |    8 |
|    3 |    9 |
|    4 |    8 |
+------+------+

How to use the updated structure?

The technique is pretty much the same as used before, but with a small modification in the application code – it has to randomly choose a row that gets updated though the value of id column.
UPDATE hits SET cnt = cnt + 1 WHERE id = 3;

Of course, with such modification the way data is read has to change as well.

mysql> SELECT SUM(cnt) FROM hits;
+----------+
| SUM(cnt) |
+----------+
|       35 |
+----------+

Even though MySQL has to perform more work, the solution can scale better than the original design.

Often using one table per “counter” will not be so good idea, but of course there’s no problem extending this further. For example:

CREATE TABLE `hits` (
`slug` VARCHAR(32) NOT NULL,
`slug_id` tinyint(4) NOT NULL,
`cnt` int(11) NOT NULL,
PRIMARY KEY (`slug`, `slug_id`)
) ENGINE=InnoDB

Some counters could have only one row, while those updated more frequently could have multiple.

PlanetMySQL Voting: Vote UP / Vote DOWN

I’d had some difficulty manually creating my own windows service for MariaDB (worked fine from the installer), but it was due to the way I was creating it, so I wanted to share the proper approach:

Old Way:

sc create "maria55" binpath= "\"C:/Program Files/MySQL/MariaDB 5.5/bin/mysqld\"
\"--defaults-file=C:/Program Files/MySQL/MariaDB 5.5/data/my.ini\""
DisplayName= "Maria55" start= "auto"

New Way:

sc create "maria55" binpath= "\"C:/Program Files/MySQL/MariaDB 5.5/bin/mysqld\"
\"--defaults-file=C:/Program Files/MySQL/MariaDB 5.5/data/my.ini\" maria55"
DisplayName= "Maria55" start= "auto"

The key is adding the name, maria55, after the –defaults-file=.. option, but still within the “” that belong to “binpath”.

This extra parameter exists so that mysqld knows whether or not it was started as a service or not.

Without it, the server does not know, and therefore didn’t realize it was running as a service, and thus since the service manager got no response from mysqld, it terminated the service after 30 seconds (though I could connect and issue any MySQL command or query within that 30 seconds).

Many thanks to Wlad for helping me to track this down!

For reference, here is my terminal output:

C:\>sc create "maria55" binpath= "\"C:/Program Files/MySQL/MariaDB 5.5/bin/mysqld\"
\"--defaults-file=C:/Program Files/MySQL/MariaDB 5.5/data/my.ini\" maria55"
DisplayName= "Maria55" start= "auto"
[SC] CreateService SUCCESS

C:\Users\Chris>net start maria55
The maria55 service is starting.
The maria55 service was started successfully.

With the initial service attempt, the service creates fine, but fails after 30 seconds:

C:\Users\Chris>net start maria55
The service is not responding to the control function.

More help is available by typing NET HELPMSG 2186.

Hope this helps.

 

PlanetMySQL Voting: Vote UP / Vote DOWN

I just wanted to take a moment and say congratulations to all of the 2012 Community Contributor Award Winners!

The usual suspects, Baron, Sarah, Gerardo, and Sheeri, each won, and deservedly so. All 4 contribute a great deal to the MySQL Community and ecosystem, and it is very much appreciated.

However, I was especially happy to hear that James Day was also a winner (a name everyone might not be so familiar with). But, having worked with James for 5 years, I really couldn’t say it better than Henrik Ingo already did (in his initial post of this year’s winners), so let me quote him:

“James was nominated for ‘MySQL advocacy and swimming upstream to keep people informed about bugs and other issues.’ When looking into James’ activities in the community, the panel first didn’t find much evidence to support an award. For instance, unlike most winners, he is not a frequent blogger on Planet MySQL. But when digging deeper it became clear that James’ instead is a very active commenter on everyone else’s blogs, contributing in depth additional information to the community dialogue. James therefore is an excellent example of the kind of helpful support person that tirelessly helps everyone he meets in their use of MySQL.”

There is not a single bug comment from James that I don’t appreciate, and he gladly shares his in-depth knowledge, and always has.

So this was definitely great to see, and that award, as were all, were well deserved!

Congratulations, James, Baron, Sarah, Gerardo, and Sheeri!

 

PlanetMySQL Voting: Vote UP / Vote DOWN

I am very pleased to say that earlier today, SkySQL announced it has raised $4 Million in Series A Round Funding.

Let me post the main part of the press release here:

SAN JOSE – April 18, 2012 – SkySQL, the first choice in affordable database solutions for the MySQL® and MariaDB® databases in the enterprise and the cloud, today announces that the company has raised $4 million in Series A funding from a number of investors, including OnCorps, an elite peer-based community of veteran technology investors and advisors committed to bringing better, cost-disruptive technologies into the mainstream. Also funding the round are European investors including Finnish Industry Investment Ltd., Spintop Ventures and Open Ocean Capital.

SkySQL will primarily use the investment to fund growth in its new product development, including adding critical positions. This is the company’s most recent move in expanding beyond a MySQL and MariaDB services-only company into a fully-fledged database products and services provider. SkySQL made its debut in October 2010 and has been funded to date with seed money from OnCorps, as well as Open Ocean Capital. Today, SkySQL is currently operating in 13 countries.

“The SkySQL strategy aligns well with OnCorps’s technology leadership vision,” said Bob Suh of OnCorps. “SkySQL will capitalize on the growing database and cloud services market. We are delighted and look forward to working with the SkySQL team to contribute to their continued success.”

“This investment will let us focus on ramping up development and efforts behind both enterprise and cloud database products that address a very real need in the marketplace,” said Ulf Sandberg, chief executive officer of SkySQL. “We also plan to build on our existing MySQL and MariaDB services offering, which offers customers unrivaled support, consulting and training.”

You can read the full press release here:

http://www.skysql.com/news-and-events/press-releases/skysql-raises-4-million-series-round

Very exciting times!

 

PlanetMySQL Voting: Vote UP / Vote DOWN

Last week was full of exciting news for all things MySQL.

However, SkySQL also had some great individual news in that it announced 2 new partners:

• hastexo
• PalominoDB

I just wanted to take a moment and officially welcome both to the SkySQL fold!

PalominoDB and hastexo, it’s great to be partnered with you!

And we’re looking forward to all the exciting things the future has to hold!

For those interested, you can read more about each partnership here:

SkySQL & hastexo Partnership Press Release
SkySQL & PalominoDB Partnership Press Release

 

PlanetMySQL Voting: Vote UP / Vote DOWN