OOW17 is just around the corner. And again this year the MySQL team is very proud to present you their work mostly on MySQL 8.0 but also on NDB and all Enterprise tools we have. This year, we will also focus on the place MySQL has in Oracle’s Cloud !

Of course MySQL’s Community is also present in the schedule with very interesting talks. The full schedule related to the MySQL sessions can be found here.

Let’s focus on the agenda for the event:

Sunday, October 1st Moscone South Room 160

• …

From September 25th to 27th 2017, the MySQL engineers and community team will be speaking at Percona Live Europe in Dublin.

MySQL is also part of the contributing sponsors.

For the conference, we tried to bring new faces to the Community. Usually, it’s always the same famous team leaders speaking at the conferences, this time, it’s not. A lot of key developers will present their own work. We have so much talented people in MySQL we want to present to our community.

Of course, once again we will focus our talks on MySQL 8.0. This is the list of sessions the MySQL Team will deliver:

Monday, Sep 25th

On Monday, I will deliver a tutorial with my friend …

I do not care much about MySQL 8.0.x at the moment, as it's far from being GA and is work in progress. It is not yet used by customers whom I have to support. But I know about many interesting changes and improvements there that, eventually, are going to influence all main forks and kinds of MySQL. So, it would not be wise to ignore MySQL 8.0.c entirely even for me.

For this post I decided to briefly check what community reported bugs were fixed in the recent release, 8.0.2, based on release notes. For me it's a measure of community interest in MySQL 8.0.x and Oracle's interest in further working with MySQL Community. I ended up with the following, short enough list of bug fixes in the categories I usually care about (InnoDB, partitioning, replication and optimizer):

• The very first InnoDB bug mentioned in …

Today is my last day in Asia (China and Taiwan), and between the sessions I had the time to code a small proof-of-concept for people that are asking how they could read their writes on all nodes and ensure the read consistency with their last write ?

The usual (and easier) answer to this particular question is to read on the same host you just wrote. But currently MySQL provides you all the elements to force a consistent read across all the nodes of a group.

Since MySQL 5.7.5, we introduced session_track_gtidsand in 5.7.6 we also introduced  GTIDs context to the OK packet (session tracker) (WL#6128 and WL#6972). So we can use this implementation in …

Recently I wrote a blog post on how to use ProxySQL with 8.0.2 dmr

This blog post was related to the change we implemented in the Group Replication’s monitoring (performance_schema tables) and how sys schema should be changed to modify the view used by ProxySQL according.

However, I used my labs machines that I was using for different purposes too and some changes I made hid a problem that avoid ProxySQL to work with the new defaults in MySQL 8.0.2. Thank you Andy for discovering this.

In fact the new collation default (utf8mb4_0900_ai_ci) is not yet supported by ProxySQL …

Some time ago I wrote this article explaining how to find which node was the Primary Master in a MySQL Group Replication cluster running in Single-Primary Mode.

In the latest release of Group Replication, MySQL 8.0.2 dmr, Jaideep improved the visibility of Group Replication extending the performance_schema tables (see his article).

Thanks to these improvements, it’s now very easy to find which host is acting a Primary-Master. This is the query you can use:

mysql-sql> SELECT MEMBER_HOST as `PRIMARY` 
           FROM performance_schema.replication_group_members 
           WHERE MEMBER_ROLE='PRIMARY';
+---------+
| PRIMARY |
+---------+
| mysql3  |
+---------+
1 row in set (0.00 sec) …

As you may know by now, MySQL 8.0.2 DMR is out ! \o/

Many features have been added (see Geir Høydalsvik‘s announcement) and of course the replication also brought new features and improvements (see this post from Luís Soares).

But some improvements in the monitoring broke the added sys view used by ProxySQL to monitor the state of a member of the group:

mysql> select * from sys.gr_member_routing_candidate_status;
+------------------+-----------+---------------------+----------------------+
| viable_candidate | read_only | transactions_behind | transactions_to_cert | …

Today I presented MySQL InnoDB Cluster at the Helsinki MySQL User Group.

To demonstrate how easy it’s to deploy a cluster with MySQL Shell and used the prompt that will be part of a future release just because it’s beautiful.

If you also want to see how it looks like, just check the video below:

There were several MongoDB users in the audience and I got only very positive feedback, they were very surprised how easy it’s to deploy a MySQL InnoDB Cluster these days !

Taking a logical backup of a member of a Group Replication Cluster is not something very easy.

Currently (5.7.17, 5.7.18 or 8.0.0) if you want to use mysqldump to take a logical backup of your dataset, you need to lock all the tables on the member you are taking the dump. Indeed, a single transaction can’t be used as savepoints are not compatible with Group Replication.

[root@mysql3 ~]# mysqldump -p  --single-transaction --all-databases --triggers \
                      --routines --events >dump.sql
Enter password:
mysqldump: Couldn't execute 'SAVEPOINT sp': The MySQL server is running with the 
--transaction-write-set-extraction!=OFF option so it cannot execute this 
statement (1290)

So we need to use:

[root@mysql3 ~]# mysqldump -p  --lock-all-tables --all-databases --triggers \
                      --routines --events >dump.sql
Enter password:

This can have a negative effect on the full Group’s …

A few months ago I wrote about showing the hidden tables in MySQL 8 data dictionary. What I presented there was a naïve solution, which I am now able to improve with a few (bold) moves. In the solution given in my previous article, I was able to guess the table names somehow, but they were still hidden from the catalog. I did not think clearly then. I should have used the data dictionary itself to see the tables. Here, in addition to getting the real list of tables, I offer a feature to unhide them permanently.

MySQL-Sandbox 3.2.08 has now the ability of un-hide the data dictionary tables, and keep them available for inspection. This feature came to my mind after a chat with the MySQL team during PerconaLive 2017. They stressed the …