Over the past few days extensive conversations around a new security vulnerability in MariaDB and MySQL have taken place.

It all started as a chain reaction when Monty Program publicly disclosed information about the flaw they had found and about how to make sure your MariaDB and MySQL installations can be fixed. The initial information got assigned the security vulnerabitlity identifier CVE-2012-2122 and the contents can be seen e.g. here http://seclists.org/oss-sec/2012/q2/493 .

The bug was found two months ago on April 4th.

read more

Over the past few days extensive conversations around a new security vulnerability in MariaDB and MySQL have taken place.

It all started as a chain reaction when Monty Program publicly disclosed information about the flaw they had found and about how to make sure your MariaDB and MySQL installations can be fixed. The initial information got assigned the security vulnerabitlity identifier CVE-2012-2122 and the contents can be seen e.g. here http://seclists.org/oss-sec/2012/q2/493.

The bug was found two months ago on April 4th.

Before disclosing the information publicly, given the seriousness of this bug and considering the millions of MySQL and MariaDB installations deployed worldwide, Monty Program informed the biggest distributors of MySQL and MariaDB as a precaution.

On April 6th, Monty Program informed Oracle about it in bug report …

If you want to be part of the team that creates the official Oracle training on MySQL and meet the following criteria ...

• Experience of course design
  

• Experience with databases such as MySQL
• Fluent in English - written and spoken
• Keen to keep on learning

... then this is the opportunity for you!

Learn more about our open position for MySQL Curriculum Developer here.

Are you looking to expand your knowledge about MySQL and MariaDB database solutions?

Well, you’re in luck! SkySQL is introducing an exclusive collection of educational videos featuring some of the industry’s leading experts on the MySQL database and related technologies. View informative, technical talks on a variety of topics, from the experts at SkySQL, MariaDB, Calpont InfiniDB, Continuent, ScaleDB, Severalnines, Sphinx, Webyog, and others.

read more

Cloud-powered BLOB type provides ACID guarantees and fast direct access to blobs via Web URLs.

Storing unstructured data

Typically unstructured data (such as pictures, media files, documents)

a) Is either stored on the file system, unlike the related with it relational data which is stored in the database. This is well known, “convenient” practice that allows fast access to files but offers no transactional story and no unified data management (for db and filesystem)

b) Or is stored in BLOBs. This ensures transactional consistency and reduces management complexities, but is really bad for performance and scalability.

We took advantage of the cloud, and came up with an upgrade to the BLOB – a solution that combines the benefits of the two.

Weblob data type

Weblob is a new data type that is supported by the Cloud Storage Engine for MySQL ( …

If you want to be part of the team that creates the Official Oracle Training on MySQL and meet the following criteria:

• Experience of Course Design and Development
• Experience of database such as MySQL
• Fluent in English - written and spoken
• Keen to keep on learning

Then this is the opportunity for you!

Learn more about our open position for MySQL Curriculum Developer here.

Earlier this week we pushed to Github the sixth iteration of Twitter MySQL. Here's some highlights:
Bugs Fixed

• Bug#65469: Infinite loop when opening a corrupted table If a permanently corrupted page was read, InnoDB would forever keep trying to read the page.
• Bug#65310: Crash with partition pruning and impossible condition Reading from a partitioned table using a impossible (e.g. where, between, etc) condition could lead to a crash if all partitions are pruned and the optimizer attempts to obtain the number of rows in the table. The problem occurs because even though no partitions are used, the optimizer might still attempt to perform (e.g. range) analysis where an estimate of the the …

Since I have been discussing scripting lately I thought I would continue with another topic I touched on briefly - backups.

I have written and modified the following script over the last few years. I have used it (and continue to use it) with multiple clients. It uses Percona's Xtrabackup to take the backup (although it can be easily modified to use mysqldump instead).

First the script

-----------------------------------------------------------------------------------------------------------------

#!/bin/bash
SAVEIFS=$IFS
IFS=$""
day_of_week=`date +%a`
backup_dir=/mysql-backup/
logfile=/root/backup_log.txt
report=/tmp/report.txt
servername=slave1
email=bmurphy@paragon-cs.com
password=`cat /root/.ssh/.backup_password`

# run backup
echo ' ' > $report
echo 'The backup is now beginning:' >> $report
echo ' ' …

Flite started using MySQL replication early in our company history, and it has served us very well. Over time we have evolved from a simple active/passive master-master topology with 2 databases in one data center to a more complex topology with multiple data centers and several different tiers of read-slaves below our master databases.

Replication lag occurs in many MySQL deployments, leading to race conditions and other application problems. This often happens with a high volume of writes to the database, but all it takes is one slow insert/update/delete query to cause the slave to fall behind.

At Flite we've generally been able to avoid replication lag. Here are a few of the tricks we use for that purpose:

0) Monitor replication

This is fundamental enough that it gets to be #0. The first thing you need to do is monitor your slaves to see if they are behind …

Flite started using MySQL replication early in our company history, and it has served us very well. Over time we have evolved from a simple active/passive master-master topology with 2 databases in one data center to a more complex topology with multiple data centers and several different tiers of read-slaves below our master databases.

Replication lag occurs in many MySQL deployments, leading to race conditions and other application problems. This often happens with a high volume of writes to the database, but all it takes is one slow insert/update/delete query to cause the slave to fall behind.

At Flite we've generally been able to avoid replication lag. Here are a few of the tricks we use for that purpose:

0) Monitor replication

This is fundamental enough that it gets to be #0. The first thing you need to do is monitor your slaves to see if they are behind …