Showing entries 21 to 30 of 1101
« 10 Newer Entries | 10 Older Entries »
Displaying posts with tag: General (reset)
Migrating to MySQL 8.0 for WordPress – episode 2: workload analysis

Now that MySQL is upgraded to 8.0 RC1, let’s have a look on how we could check the workload and see if we can optimize something by adding indexes for example. The same technique can be used to find inefficient queries requiring rewriting.

The first thing we will check is some information regarding the usage of the user used for lefred.be’s website:

mysql> select * from sys.user_summary where user= 'wp_lefred'\G
*************************** 1. row ***************************
user: wp_lefred
statements: 65060
statement_latency: 2.71 m
statement_avg_latency: 2.50 ms
table_scans: 234
file_ios: 17151
file_io_latency: 54.83 s
current_connections: 0
total_connections: 2541
unique_hosts: 1
current_memory: 52.27 MiB
total_memory_allocated: 12.50 GiB

This was after the upgrade, so not much info yet but if I compare with the other sites hosted on …

[Read more]
👋 🐛 199 – bye bye bug #199, MySQL auto_increment is fixed !

It was expected for a long time…. here is the fix for bug #199 !!

The bug #199 submitted by PeterZ has been fixed in 8.0. Thank you to Zhang Simon for his contribution that inspired us to implement the fix.

Let’s have a look at the test case described in the bug report, I will reproduce it on MySQL 5.7.19 & MySQL 8.0.3.

The initial steps are exactly the same on both versions:

mysql> create table a(id int unsigned not null primary key auto_increment);
Query OK, 0 rows affected (0.17 sec)

mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(10) unsigned …
[Read more]
MySQL Team speaking at Percona Live Dublin 2017


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 …

[Read more]
MySQL Group Replication: read your own write across the group

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 …

[Read more]
MySQL Group Replication is sweet… but can be sour if you misunderstand it ;-)

Recently, my friend Marco Tusa(MySQL Daddy or the Grinch) wrote his first impression on MySQL Group Replication (part of InnoDB Cluster). And his conclusion was not that positive. But when I analyze his setup, I understand that his assumptions were not so right.

Let's try to explain what were the issues and why his test wasn't correct.

Before commenting Marco's tests, I would like to clarify the flow-control implementation in Group Replication:

We designed the flow-control feature in Group Replication as a safety measure for delaying writer nodes when they consistently exceed the write capacity of the Group, so that a large backlog would not make it hard to switch over from a member to another.

Flow-control is …

[Read more]
MySQL Group Replication: understanding Flow Control

When using MySQL Group Replication, it’s possible that some members are lagging behind the group. Due to load, hardware limitation, etc… This lag can become problematic to keep good certification behavior regarding performance and keep the possible certification failure as low as possible. Bigger is the applying queue bigger is the risk to have conflicts with those not yet applied transactions (this is problematic on Multi-Primary Groups).

Galera users are already familiar with such concept. MySQL Group Replication’s implementation is different 2 main aspects:

  • the Group is never totally stalled
  • the node having issues doesn’t send flow control messages to the rest of the group asking for slowing down

In fact, every member of the Group send some statistics about its queues (applier queue and certification queue) to the other members. Then every node decide to slow down or not if they …

[Read more]
Debian 9 released with MariaDB as the only MySQL variant

The Debian project has today announced their 9th release, code named “Stretch”. This is a big milestone for MariaDB, because the release team decided to ship and support only one MySQL variant in this release, and MariaDB was chosen over MySQL. This is prominently mentioned in the press release about Debian 9 and more information […]

The post Debian 9 released with MariaDB as the only MySQL variant appeared first on MariaDB.org.

Two version upgrade fun with MySQL 5.5 to 5.7

In a perfect world, one would upgrade databases one version at a time and not let them get too old.  But our databases are where the “crown jewels” are.  They must stay up 24×7.  When performance is acceptable, it’s acceptable, and sometimes old versions stay around too long.  We don’t live in a perfect world.  This idea applies to so many things.  There’s almost never a perfect data model.  There is always some type of resource constraint be it storage, memory, CPU, IOPS, or just plain dollars.

I will bring this concept of not living in a perfect world into a discussion about upgrades.

Ideally there would be…

  • …time to do two upgrades.  One upgrade to 5.6, the other to 5.7.   This is the way sane, normal people upgrade.
  • …a lot of extra hardware.  It sure would be nice to maybe combine a maintenance like this with a hardware refresh so that …
[Read more]
MySQL InnoDB Cluster: Automated Installation with Puppet

We saw yesterday that the new MySQL Shell was out and how we could create a MySQL InnoDB Cluster manually using the Shell.

Today, I would like to show you how easy it is to create recipes to automate all the process. I have created a Puppet module that can be used as Proof-of-concept (You might need more features to use it in production, feel free to fork it).

The module can be found on this github repo.

When using Puppet, I really like to put all configuration in hiera.

Environment

We have 3 GNU/Linux servers: mysql1, mysql2 and mysql3.

We won’t install anything related to MySQL manually, everything will be handled by Puppet.

Nodes definition …

[Read more]
MySQL Group Replication, Single-Primary or Multi-Primary, how to make the right decision ?

Today’s blog post is related again to MySQL Group Replication.

By default MySQL Group Replication runs in Single-Primary mode. And it’s the best option and the option you should use.

But sometimes it might happen that in very specific cases you would like to run you MGR Cluster in Multi-Primary mode: writing simultaneously on all the nodes member of the Group.

It’s of course feasible but you need to make some extra verification as not all workload are compatible with this behavior of the cluster.

Requirements

The requirements are the same as those for using MGR in Single-Primary mode:

  • InnoDB Storage Engine
  • Primary Keys
  • IPv4 Network
  • Binary Log Active
  • Slave Updates Logged
  • Binary …
[Read more]
Showing entries 21 to 30 of 1101
« 10 Newer Entries | 10 Older Entries »