InnoDB Cluster in a Nutshell Part 3: MySQL Shell

MySQL InnoDB Cluster MySQL ShellWelcome to the third part of this series. I’m glad you’re still reading, as hopefully this means you find this subject interesting at least. Previously we presented the first two components of MySQL InnoDB Cluster: Group Replication and MySQL Router and now we will discuss the last component, MySQL Shell.

MySQL Shell

This is the last component in the cluster and I love it. Oracle have created this tool to centralize cluster management, providing a friendly, command-line based user interface.

The tool can be defined as an advanced MySQL shell, which is much more powerful than the well known MySQL client. With the capacity to work with both relational and document (JSON) data, the tool provides an extended capability to interact with the database from a single place.

MySQL Shell is also able to understand different languages:

  • JavaScript (default) which includes several built-in functions to administer the cluster—create, destroy, restart, etc.—in a very easy way.
  • Python it provides an easy way to write Python code to interact with the database. This is particularly useful for developers who don’t need to have SQL skills or run applications to test code.
  • SQL to work in classic mode to query database as we used to do with the old MySQL client.

A very interesting feature provided with MySQL Shell is the ability to establish different connections to different servers/clusters from within the same shell. There is no need to exit to connect to a different server, just issuing the command \connect will make this happen. As DBA, I find this pretty useful when handling multiple clusters/servers.

Some of the features present in this tool:

  • Capacity to use both Classic and X protocols.
  • Online switch mode to change languages (JavaScript, Python and SQL)
  • Auto-completion of commands using tab, a super expected feature in MySQL client.
  • Colored formatting output that also supports different formats like Table, Tab-separated and Json formats.
  • Batch mode that processes batches of commands allowing also an interactive mode to print output according each line is processed.

Some sample commands

Samples of new tool and execution modes:

Personally, I think this tool is a very good replacement for the classic MySQL client. Sadly, mysql-server installations do not include MySQL shell by default, but it is worth getting used to. I recommend you try it.


We finally reached the end of this series. I hope you have enjoyed this short introduction to what seems to be Oracle’s bid to have a built-in High Availability solution based on InnoDB. It may become a good competitor to Galera-based solutions. Still, there is a long way to go, as the tool was only just released as GA (April 2018). There are a bunch of things that need to be addressed before it becomes consistent enough to be production-ready. In my personal opinion, it is not—yet. Nevertheless, I think it is a great tool that will eventually be a serious player in the HA field as it’s an excellent, flexible and easy to deploy solution.

Share this post

Comments (4)

  • Ken Medley

    Great blog post!

    July 20, 2018 at 3:24 pm
  • lefred

    Hi Francisco,

    Of course I cannot decide on your opinion which is yours, but you write that there is still a long way to go without any arguments… or at least the one pointed in your 3 articles series are not obvious. Of course there may be features required for certain environment that you are missing, but please share them then.
    Thank you.

    July 22, 2018 at 12:52 pm
  • Francisco


    Fair enough, as you mentioned, this is my personal opinion and not necessarily same than Percona’s. Far from starting an argument here I’d point 2 things I think are enough to consider group replication as no go (yet):
    1- Consistency: you can’t really prevent a node going out of sync in terms of data if there is a user with enough privileges, i.e. running DDLs with sql_log_bin=0. I know this is an edge case but is really easy to reproduce and in this case offending node will be set out of the cluster with a replication error that needs to be fixed manually (and with GTID this might not be trivial)
    2- Node auto provisioning: backing to problem one, or even adding a new node to cluster. You have to provision node manually and this requires manual intervention which in my opinion goes against the high availability concept.

    I know a lot of work is being done to address these things but afaik they are not open to be tested now, so that’s why I’m pointing there is long way to go. Hopefully we will see these things addressed soon.


    July 23, 2018 at 2:02 pm

    Hi Fransisco

    Great intro to all the 3 parts of innodb cluster. Small rectification in this post u may make, same command is written twice 🙂

    #rejoin instance to cluster – needs to be executed locally to the instance
    #rejoin instance to cluster – needs to be executed locally to the instance

    January 15, 2019 at 12:08 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.