As documented in the Reference Manual MySQL supports a maximum of 16 columns per index. That's more than sufficient for most index use cases, but what about unique constraints? If I create a fact table with more than 16 dimension columns in my star schema, and then try to add an index to enforce a unique constraint across all of the dimension columns, then I'll get this error:

ERROR 1070 (42000): Too many key parts specified; max 16 parts allowed

For multi-column unique indexes, internally MySQL concatenates all of the column values together in a single hyphen-delimited string for comparison. Thus I can simulate a multi-column unique index by adding an extra column that stores the concatenated column values, and adding a unique index on that column.

Read on for details...

I could populate the new column …

Indeed, MySQL 5.7 rocks ;-)

This is the part1 of the following blog posts about various benchmark results on MySQL 5.7 - and this particular one is dedicated to the Sysbench OLTP_RO Point-Select 8-tables workload.

We've already published the over 500K QPS on SQL Point-Selects before @32cores-HT server, so may reconfirm it again with MySQL 5.7 DMR5 -vs- other engines :


and now on a similar server, but with 40cores-HT we're able to confirm 645 QPS on the same workload!

If you missed the long story about how we arrived on such a performance level and how to reproduce the test - you may find all here. This workload is the most killing from all Read-Only Sysbench OLTP tests.. And it's really for the first time we started to scale here with MySQL! …

In this third installment in this series, I'll explain why the smart solution I described in the previous post actually wasn't that good, and then I go on to explain how to fix it, and why that fix wasn't such a smart thing after all. So, this was the design we ended with last time:
We have Oracle replicating to a Materialized View, this to ensure that we can run triggers when the is a commit, and then triggers on this Materialized View updates MariaDB by sending a UDP message to a server that in turn is connected to MariaDB.

The issue with the above thingy was that a Materialized View by default is refreshed in it's entirety when there is a refresh, so if the table has 10.000 rows and 1 …

Business Wire  Oracle Open World 2014, Booth # 430- Continuent, Inc., a leading provider of open source database clustering and replication solutions, today announced Continuent Tungsten 3.0, a powerful solution that combines advanced clustering and replication technologies to meet the transaction processing and analytic needs of the entire business. Continuent Tungsten 3.0 enables constant,

MySQL Fabric 1.5.2 is out. In this release, you will find fixes for some bugs and, specially, new exciting features:

New interface using the MySQL Protocol

Now MySQL Fabric mimics to some extent a MySQL Server. This will foster the MySQL Fabric adoption by other connectors as they will not have to use a XML-RPC protocol.

import mysql.connector

cnx = mysql.connector.connect(host='localhost', port=32275, user='admin', password='adminpasswd')

cur = cnx.cursor()

cur.execute("CALL dump.servers(patterns=%)", multi=True)
print cur.column_names
for row in cur.fetchall():
print "Row", row

Provisioning command group

We have started to make MySQL Fabric Cloud Aware and exploit the easiness to spawn new machines in a cloud environment. There is a long road ahead and this is just the beginning.

$ mysqlfabric provider register my_provider user passwd \ …

Get a preview of the next advance in data management technology!  Continuent Tungsten 3.0 brings the power of advanced clustering and replication to offer data management needs for your entire business including MySQL high availability, disaster recovery, multi-master operation, and real-time data warehouse loading. With Continuent Tungsten you can apply the full power not just of MySQL but all

The MaxScale team have been working hard fixing bugs and improving performance. On Friday we released a update of MaxScale, the pluggable proxy for MySQL and MariaDB, I wanted to write a little about a few of those changes. I will not mention every change, there are release notes that give the list of bugs fixed in this version, but rather highlight a couple of performance related changes and describe the rationale behind them. However before I start on the two items I wanted to discuss just a quick note to say that this version introduces cmake as the means to build MaxScale. The previous Makefiles are still available in this version, but will be withdrawn in future versions as we transition to cmake for build, installation and packaging.
Connection StarvationIn one of the test scenarios that I was …

We have relocated the MySQL Connector/Python repository on GitHub to the following location:

https://github.com/mysql/mysql-connector-python

The old location will redirect to the above URL.

No, we have not updated the README.txt or made something special for GitHub. I personally don’t mind what is currently showing on GitHub: it is readable, and it is correct. I still hope GitHub will make it easier to show something else, like asking which document to display and as what format.

We have relocated the MySQL Connector/Python repository on GitHub to the following location:

https://github.com/mysql/mysql-connector-python

The old location will redirect to the above URL.

No, we have not updated the README.txt or made something special for GitHub. I personally don’t mind what is currently showing on GitHub: it is readable, and it is correct. I still hope GitHub will make it easier to show something else, like asking which document to display and as what format.

The theme for this series of posts is, and indicated in the previous post, "Try and try, again", and there will be more of this now when I start to make this work by playing with Oracle, with PL/SQL and with the restrictions of Oracle Express (which is the version I have available).

So, what we have right now is a way of "sending" SQL statements from Oracle to MariaDB, the question is when and how to send them from Oracle. The idea for this was then to use triggers on the Oracle tables to send the data to MariaDB, like this, assuming we are trying to replicate the orders table from Oracle to MariaDB:
In Oracle, and assuming that the extproc I have that created to send UDP …