Shinguz's blog

With MySQL 5.0 the database provides trigger functionality on INSERT, REPLACE, UPDATE and DELETE.

Recently the question came up if it is faster to restore a MySQL cluster when all nodes are up or only ONE node from each node group during restore.

What is MyEnv?

FromDual MyEnv is a database environment to run and operate several different MariaDB, MySQL or PostgreSQL database instances simultaneously on the SAME machine. You can even run multiple database instances with different binary versions. We call this multi-instance set-ups.

It is possible to use an active - active shared-disk cluster in MySQL in some cases. For doing this you have to fulfill the following requirements:

Transaction performance relates among other things from I/O performance. This means hard disk performance.

In a round-robin database (RRD) usually time-series data like network bandwidth, temperatures, CPU load etc. is stored. The data is stored in the way that system storage footprint remains constant over time. This avoids resource expensive purge jobs and reduces complexity.

The price for a 160 Gbyte disk will be around USD 15'000. This is still a bit expensive. But the access time is around 0.5 ms (both for reading and writing) which is around 10 times faster than a normal 15'000 rpm SCSI disk! The disk has NO cache because it is a cache itself (according to the supplier. Maybe this will change in the future). And the lifetime of a cell is > 5 mio writes. For the same performance one needs usually an array of around 10 disks. If your database is heavily write-I/O bound you should consider this solution.

MySQL provides its replication for High Availability (HA) and for read Scale-out. Generally it is known that in a MySQL replication you can only replicate from one Master to many slaves. In this paper it is shown how a set-up can look like to replicate from two masters to one slave.

Probably the answer to this question is already known. But we want to prove it and by the way learn to deal with MySQL and oprofile.

Materialised View (MV) is the pre-calculated (materialised) result of a query. Unlike a simple VIEW the result of a Materialised View is stored somewhere, generally in a table. Materialised Views are used when immediate response is needed and the query where the Materialised View bases on would take to long to produce a result. Materialised Views have to be refreshed once in a while. It depends on the requirements how often a Materialised View is refreshed and how actual its content is. Basically a Materialised View can be refreshed immediately or deferred, it can be refreshed fully or to a certain point in time. MySQL does not provide Materialised Views by itself. But it is easy to build Materialised Views yourself.

A Federated Table is a table which points to a table in an other MySQL database instance (mostly on an other server). It can be seen as a view to this remote database table. Other RDBMS have similar concepts for example database links.

We have added some more tools to our MySQL consulting tools collection.

We have added some more database benchmarks to our collection.

One of the big advantages of MySQL is its concept of pluggable Storage Engines (SE). This means you can choose the most optimal storage engine for your needs. This also has a disadvantage: You have to know what you are doing…

MySQL has also a Full-Text Search Engine built in. But this Search Engine is not as fast a you probably want to. Thus there are some alternative Full-Text Search Engines which might be working together with MySQL.

Applications occasionally require redesign. However, redesigning an application cannot be done in one step because the application is distributed or several versions of applications must be supported. MySQL 5.0 provides the necessary means to stealthy migrate your data. In a short overview let’s look at what we plan to do: Stealthy Migration (PDF 98.7 kByte).