Connector/J 8.0.11, the Face for Your Brand New Document-oriented Database

This is exciting news: MySQL 8.0 is officially GA!

This time around we do not only offer you a new MySQL Server full of exciting new features, but also a brand new toolset that let you make the most out of MySQL, including the now GA Java database driver, MySQL Connector/J 8.0.11!

This story is about Connector/J but before even I get started I must say a few words about the new features that conducted the development of this new driver. If you prefer, you can jump directly to the Connector/J 8.0 topic below.

What’s new in MySQL Server 8.0?

There’s a new Client/Server communication protocol in MySQL: the X Protocol

The X Protocol introduced in MySQL 8.0 series is the backbone for the document-oriented paradigm in the MySQL ecosystem. The new X Protocol and the old MySQL Client/Server Protocol are both available in this new MySQL Server. It is up to the clients to choose which one to implement for connecting to MySQL servers, either through pure protocol implementations or via a MySQL C API library, for example. Clearly the easiest option is to use one of the MySQL connectors that already implement either one or both of the protocols that we offer for the programming language of your choice.

The X Protocol is implemented as a plugin for the MySQL Server—the X Plugin. By default the X Plugin is listening on TCP port 33060.

Among the main features in the X Protocol you’ll find data serialization via Protocol Buffers, Vectored I/O, Pipelining, SASL authentication, extensible messages via protobuf, and so on. We are also working on other interesting features so stay tuned. I invite you to go to the X Protocol documentation to learn all about it.

So, there’s also the new X Plugin

As mentioned before, the X Plugin implements the X Protocol on the MySQL Server side.

Besides implementing the X Protocol, the X Plugin is responsible for defining the message structure that provides the base for the X DevAPI – the API that exposes a MySQL server as a document-oriented database. It is also responsible for communicating with the internal components of the server: the storage engines, the query parser, the query optimizer, query executors, and so on. In the other end, it also manages all active X DevAPI sessions and handles clients’ requests.

As of MySQL 8.0 GA the X Plugin is loaded by default. Chances are that it is already available for you in your new server installation.

Knowledge of the X Plugin will provide you insights into the features of the X DevAPI as well as how MySQL handles those features. The X Plugin documentation is, again, your best companion for learning about the plugin.

MySQL as a document-oriented database: the X DevAPI

It is through the new X DevAPI that the document-oriented database features in MySQL are exposed. This is how you use MySQL as a document store, a schema-less, and therefore schema-flexible storage system for documents. When using MySQL as a document store you do not need to know and define all possible attributes of your data before storing and operating with it. This differs from working with a relational database and storing data in a table, where all columns of the table must be known and defined before adding data to the database.

Long ago MySQL added support for JSON data along with a large variety of functions and operations that allow creating, manipulating, and handling JSON structures and values. This new data type combined with the old and reliable InnoDB based tables, with the ability to create dynamically generated columns and indexes over them, constituted the right environment for spawning MySQL’s interpretation of our document store.

The X DevAPI provides you with a unifying API for creating and handling documents in JSON format in MySQL, which you can use to develop applications. It offers a modern programming interface with a simple yet powerful design that provides support for established industry-standard concepts. One of the major keynotes in the X DevAPI is harmony you get when working with different MySQL Connectors that implement it. It becomes so easy for a developer to switch between different programming languages and still get the same “look & feel” from different Connectors.

Although MySQL Connectors are the typical entry point for using the X DevAPI, you can actually start using it even without jumping into a programming language; just try it in the new command-line client: MySQL Shell.

MySQL Reference Manual contains an overview of MySQL as a Document Store which I recommend reading. The X DevAPI User Guide is the central source of information for all common aspects of this new and exiting API.

And here’s the new MySQL command-line client: MySQL Shell

MySQL Shell is an advanced command-line client and code editor for MySQL server. In addition to the usual SQL functionality provided by the mysql client, MySQL Shell provides scripting capabilities for JavaScript and Python and includes APIs for working with MySQL. When MySQL Shell is connected to the MySQL server through the X Protocol, the X DevAPI can be used to work with both relational tables and document data.

This is the perfect companion tool for your development work with any of the new Connectors supporting X DevAPI, as it allows viewing and manipulating documents and collections easily, so that you can prototype X DevAPI calls, expressions syntax, and a lot more before starting coding them into your projects.

As of MySQL Server 8.0.11, MySQL Shell is not included in the server’s default toolset, so you will have to install it separately. Get started with MySQL Shell by downloading it from MySQL Downloads and get more info from its User Guide.

TL;DR: After all, this post is about Connector/J!

Connector/J 8.0, the new GA JDBC/X DevAPI driver for MySQL databases

I am particularly proud to announce that Connector/J 8.0 is now GA. This is the officially recommended version to use in your projects from now on. And it doesn’t matter what server version you are using.

Note that Connector/J became GA with version 8.0.11, skipping version 8.0.10, which was expected to appear after the last Release Candidate. If you haven’t heard about it, just know that several MySQL products, including Connector/J, will be version aligned with MySQL Server releases from now on. This means that you can expect new releases of Connector/J every time there is a MySQL Server 8.0 release. This doesn’t mean, however, that you must also align the Connector/J library in your projects with the server version you are connecting to. As always, our recommendation is to use the latest Connector/J library, no matter what server version you use.

Connector/J 8.0 is the rightful successor of the widely used Connector/J 5.1. Now compiled in Java 8 only, it comes with huge refactoring. Connector/J 8.0 is better organized and follows better and more up-to-date coding practices, as well as many of the exciting features of Java 8. This is also the driver to use with the new X DevAPI in the Java ecosystem.

We know that, despite our best efforts, no code is ever perfect. This is why we are continuously working on it and we really appreciate your comments and suggestions for improving this product. Therefore, please continue to use the resources we provide to get in touch with us, including the MySQL bug system, the Connector/J forum, the GitHub repository or MySQL Community Slack, with which you can talk to us directly.

Connector/J 8.0 does not only implement the JDBC 4.2 API, but also the X DevAPI for new document store features, so you can use them interchangeably. As matter of fact, the two API implementations share a lot of core base code. This is so to offer you a better user experience and versatility in your projects.

The new X DevAPI implementation provides an up to date and more user-friendly programming method with its Fluent Interface API. It all starts with obtaining a Session object, which is similar to getting a JDBC Connection, and, from then on, you have a tool to work with with Schemas, Collections and even old-style Tables. Always remember to keep Connector/J Developer Guide and the Connector/J X DevAPI Reference handy for quick reference.

Getting started with Connector/J 8.0 and X DevAPI

Initial setup & getting Connector/J binaries

Your first step should be setting up a new Java project using whatever method you prefer, immediately followed by attaching the Connector/J library. You can do it either by setting up a Maven dependency in your pom.xml or by downloading the Connector/J bundle from the official MySQL Downloads page.

In order to setup a Maven dependency just add the following in the <dependencies> section of your project’s pom.xml file, then proceed with the usual Maven commands to build and run your project:

If you choose to download the Connector/J bundle from the MySQL repositories, you must extract its contents to some temporary place and copy the following files to your project’s libraries directory:

  • mysql-connector-java-8.0.11.jar
  • lib/protobuf-java-2.6.0.jar

Instead of using the provided Protocol Buffers Java API library, you could also get protobuf-java-2.6.0.jar from its official repositories. Note that there are a few other Java libraries in the libs directory and you are not required to add them to your project if you don’t use any of the features that need them.

If you are bold enough, you can even grab the Connector/J source code and compile it yourself. This is not a task for a Java novice but you will find some help in Connector/J Developer Guide – Installing from source.

I will not go into more details but you must make sure the classpath settings include the two libraries in all further Java commands or project configurations in your IDE.

Needless to say that you will also need a MySQL Server 8.0.11 (at least) in order to proceed. If you don’t have one, you can install it in few easy steps; just choose the right package for you and follow the instructions in the Reference Manual.

Hello World, using JSON documents and X DevAPI

It is time to create the a simple demo Java class. Lets call it

You should implement proper exception handling in your application. For the sake of this demo I’ll just throw Exception  in the method main .

First thing to do is to establish a connection to the MySQL server, that is, obtaining a Session in X DevAPI terminology. Lets assume the X Plugin is listening on the default port 33060. To do this in Connector/J you first need to instantiate a SessionFactory  and then use it to create the Session  object for you:

Replace the user and password according to your database setup. The same goes for the host and port parts.

Note that jonhdoe is just a standard MySQL user. Since this user will be used to create objects in the database, please make sure that it has the required permissions to do so.

The connection string in this sample is pretty straightforward. It identifies the protocol to use (mysqlx), the user, password, hostname and port. Except for the part johndoe:password@ this is quite similar to the old JDBC connection strings. In fact, Connector/J 8.0 lets you use this same syntax for JDBC connections too.

The previous code returns a Session  object you can to use manage schemas. A Schema is essentially a MySQL database. Lets create one for this demo:

By now there should be a new database named demo in your MySQL server instance.

The Schema object you have got lets you manage collections and tables in the database. Just keep in mind that collections are just tables with a specific column structure, which you shouldn’t modify in any way other than through a X DevAPI interface.

Let’s now create a collection and add a few documents to it:

So, this creates a table named greetings in the demo database. This table has two columns: doc and _id:

The X DevAPI, through the X Plugin, manages this 1:1 mapping between the collection greetings and the table with the same name. Following X DevAPI code related to this collection operates over this relational table using a panoply of JSON functions available in MySQL server, however, all this happens internally in the server and it is transparent to clients.

Lets wrap this demo up with a couple of data retrieving operations:

This time we work with the Collection instance in order to fetch its data using two simple filters, exactly as what you would do using standard SQL tables.

The returned object DocResult  can then be used to get the list of the documents filtered from the collection. Each document is exposed as a DbDoc  instance. DbDoc  is particularly important in Connector/J X DevAPI implementation, because it represents a JSON object, something that Java doesn’t support natively.

This should be the end result of this simple demo:

With exception of the _id values, which are generated each time you add a document to a collection, you should get the same results as me, if you try out the demo.

What else?

This little demo was about a few basic CRUD operations on Collections, but there’s a lot more in the X DevAPI:

  • CRUD operations on Collections and Tables;
  • Parameter binding;
  • Document patching;
  • Various types of results and metadata;
  • Raw (SQL) statements execution;
  • Transaction save-points;
  • Row locking mechanisms;
  • Simplified expression syntax, etc.

Closing comments

MySQL Connector/J 8.0.11 is the new GA version of Connector/J for MySQL databases. It implements the X DevAPI, an exciting new feature that enables the use of MySQL Server 8.0 as a document-oriented database.

The 8.0 series of the Connector/J driver, fully re-factored from the previous GA version 5.1, requires Java 8 or above to work with. If that is a limitation for you, you can still use the Connector/J 5.1 series that supports Java 5 up to Java 8. We’ll keep maintaining the 5.1 series for the time being, but be mindful that you will only be able to use JDBC with it.

Although a feature preview version of the X DevAPI is also available in the MySQL Server 5.7 series, which you could use with Connector/J 8.0.11 and later, I recommend that you use the X DevAPI with MySQL 8.0. The X Plugin implementation in the  5.7 series has some known limitations and, most likely, no new features will be back ported to MySQL 5.7.

Exiting times are coming for all of us. Enjoy the new features we offer you and let us know what you think about them.

On behalf of the MySQL Connector/J development team, I wish you a pleasant programming experience with Connector/J 8.0.

MySQL Connector/C++ 8.0.11 GA has been released

Dear MySQL users,

MySQL Connector/C++ 8.0.11 is the first GA release version of the
MySQL Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ applications using X DevAPI or plain C applications using

To learn more about how to write applications using X DevAPI, see
“X DevAPI User Guide”

and “X DevAPI Reference” at

For more information about using plain C XAPI see “XAPI Reference” at

For generic information on using Connector/C++ 8.0, see

For X DevAPI or XAPI applications, Connector/C++ 8.0 requires
MySQL Server 5.7.12 or higher with X Plugin enabled. For
applications that use the legacy JDBC API, Connector/C++ 8.0
can use MySQL Server 5.5 or higher, and X Plugin is not required.

To download MySQL Connector/C++ 8.0.11, see the
“Generally Available(GA) Releases” tab at

Changes in MySQL Connector/C++ 8.0.11 (2018-04-19,
General Availability)

For MySQL Connector/C++ 8.0.11 and higher, Commercial and
Community distributions require the Visual C++
Redistributable for Visual Studio 2015 to work on Windows
platforms. The Redistributable is available at the Microsoft
Download Center
install it before installing Connector/C++.

Functionality Added or Changed

* Incompatible Change: When documents without an _id
attribute are added to a collection, the server now
automatically generates IDs for them. The server
determines the ID format, which should be considered
opaque from the API perspective (they are no longer
UUID-based). As before, no _id attribute is generated if
a document already contains one. User-provided document
IDs must not conflict with IDs of other documents in the
This capability requires a MySQL 8.0 GA server. If the
server does not support document ID generation, the
document-add operation returns an error indicating that
document IDs were missing.
For X DevAPI, the generated IDs resulting from a
document-add operation can be obtained using the new
Result.getGeneratedIds() method, which returns a list.
For XAPI, the generated IDs can be obtained using the new
mysqlx_fetch_generated_id() function, which returns IDs
one by one for successive calls, until it returns NULL to
indicate no more generated IDs are available. For both X
DevAPI and XAPI, document IDs specified explicitly in
added documents are not returned.
Incompatibility: The getGeneratedIds() method replaces
getDocumentId() and getDocumentIds(), which are now
removed. The mysqlx_fetch_generated_id() function
replaces mysqlx_fetch_doc_id(), which is now removed.

* A patch operation has been implemented that enables
specifying a JSON-like object that describes the changes
to apply to documents in a collection.
For X DevAPI, the CollectionModify operation supports a
new patch() clause for patching documents. For XAPI,
there are two new functions:
mysqlx_collection_modify_patch() directly executes
patching on documents in a collection that satisfy given
criteria. mysqlx_set_modify_patch() adds a patch
operation to a modify statement created with the
mysql_collection_modify_new() function.

* For connections to the server made using the legacy JDBC
API (that is, not made using X DevAPI or XAPI),
Connector/C++ 8.0 now supports an
OPT_GET_SERVER_PUBLIC_KEY connection option that enables
requesting the RSA public key from the server. For
accounts that use the caching_sha2_password or
sha256_password authentication plugin, this key can be
used during the connection process for RSA key-pair based
password exchange with TLS disabled. This capability
requires a MySQL 8.0 GA server, and is supported only for
Connector/C++ built using OpenSSL.

Bugs Fixed

* Single-document methods such as Collection.replaceOne()
did not accept expr() as the document specification, but
instead treated it as a plain JSON string. (Bug

* Compiling X DevAPI and XAPI test programs failed with an
error. (Bug #27610760)

* Connecting with an incorrect SSL_CA value could result in
a memory leak. (Bug #27434254)

* For debug builds, specifying a document as _id raised an
assertion rather than producing an error. (Bug #27433969)

As always, a big THANK YOU for using MySQL!

MySQL Connector/ODBC 8.0.11 GA has been released

Dear MySQL users,

MySQL Connector/ODBC 8.0.11 is the first GA version of the MySQL Connector/ODBC 8.0 series, the ODBC driver for the MySQL database management system.

The available downloads include both a Unicode driver and an ANSI driver based on the same modern codebase. Please select the driver type you need based on the type of your application – Unicode or ANSI. Server-side prepared statements are enabled by default. It is suitable for use with any MySQL server version from 5.5.

This release of the MySQL ODBC driver is conforming to the ODBC 3.8 specification. It contains implementations of key 3.8 features, including self-identification as a ODBC 3.8 driver, streaming of output parameters (supported for binary types only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode driver only).

Also, Connector/ODBC 8.0 has a GTK+-based setup library providing a GUI DSN setup dialog on some Unix-based systems, currently included in the Debian 9, EL6/OL6 (64-bit only), EL7/OL7 (64-bit only), Fedora 26/27, FreeBSD 11, SLES 12, and Ubuntu 14/16/17 packages.

The release is now available in source and binary form for a number of platforms from our download pages at

For information on installing, please see the documentation at

Changes in MySQL Connector/ODBC 8.0.11 (2018-04-19)

MySQL Connectors and other MySQL client tools and applications now synchronize the first digit of their version number with the (highest) MySQL server version they support. This change makes it easy and intuitive to decide which client version to use for which server version.

Connector/ODBC 8.0.11 is the first release to use the new numbering. It was branched from Connector/ODBC 5.3.10.

The Connector/ODBC 8.0 series also adds full MySQL Server 8.0 support.

Functionality Added or Changed

  • Connector/ODBC now supports a new GET_SERVER_PUBLIC_KEY connection option that enables requesting the RSA public key from the server. For accounts that use the caching_sha2_password or sha256_password authentication plugin, this key can be used during the connection process for RSA key-pair based password exchange with TLS disabled. This capability requires a MySQL 8.0 or higher server, and is supported only for Connector/ODBC built using OpenSSL.
  • A new OpenSSL runtime dependency was added that must be present on the target system where the connector is used. For some platforms it is assumed that a system-wide OpenSSL is available, for others, such as Windows and macOS, these required OpenSSL libraries are bundled in the binary packages.
  • Packaging was modified for the new MySQL Connector/ODBC 8 series. For example, the Connector/ODBC 5.x ODBC driver has a file named myodbc5w.dll, whereas this same ODBC 8.0 driver is named myodbc8w.dll for the Connector/ODBC 8.x series. The sample .ini file also references these new file names.

On Behalf of Oracle/MySQL Release Engineering Team,
Kent Boortz

MySQL Connector/J 8.0.11 GA has been released

Dear MySQL users,

MySQL Connector/J Version 8.0.11 is the first General Availability
release of the 8.0 series of MySQL Connector/J. It is suitable for use
with MySQL Server versions 8.0, 5.7, 5.6, and 5.5. It supports the
Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI.

This release includes the following new features and changes, also
described in more detail on

As always, we recommend that you check the “CHANGES” file in the download
archive to be aware of changes in behavior that might affect your application.

To download MySQL Connector/J 8.0.11 GA, see the “Generally Available (GA)
Releases” tab at


Changes in MySQL Connector/J 8.0.11   (2018-04-19)

Functionality Added or Changed

* X DevAPI: The locking options lockShared() and
lockExclusive(), available when retrieving data from
collection.find() and, now also accept an
optional locking contention value, which is exposed
though the enumeration Statement.LockContention. The
combinations of lockShared([lockCont]) or
lockExclusive([lockCont]) with
Statement.LockContention.NOWAIT or
Statement.LockContention.SKIP_LOCKED map directly to the
UPDATE with the SQL option NOWAIT or SKIP LOCKED, for the
different InnoDB locking read modes.

* X DevAPI: Connector/J now supports the new server-side
document ID generation feature. Client-side document ID
generation is no longer supported. As a result, the
methods getDocumentId() and getDocumentIds() have been
removed and the method getGeneratedIds() has been added
to the AddResult and AddResultImpl classes.

* X DevAPI: The SHA256_MEMORY authentication mechanism is
now supported by Connector/J for connections using the X
Protocol. See the entry for the connection property
xdevapi.auth in Configuration Properties
-reference-configuration-properties.html) for details.

* Connector/J now recognizes the data type GEOMCOLLECTION,
which has been introduced in MySQL 8.0.11 as an alias and
preferred name to the previously known GEOMETRYCOLLECTION
data type. (Bug #27678308)

* Connector/J now supports the use of a custom
SSLSocketFactory for returning a custom-constructed SSL
socket at the time of connection establishment. (Bug
#26092824, Bug #86278)

* The source directory and Java package layouts of
Connector/J have been revised to make it easier to use
custom protocols, APIs, value decoders, and value
factories with Connector/J. See the Connector/J source
code and the MySQL Connector/J X DevAPI Reference
( for more

Bugs Fixed

* When an integer value in a JSON document is modified, it
becomes a a DOUBLE value to the MySQL server, which is
returned with a decimal when fetched from the JSON
document. Therefore, calling getInteger() upon the
changed value with Connector/J resulted in an
NumberFormatException. With this fix, getInteger() parses
such a value correctly and returns an integer. (Bug

On Behalf of Oracle/MySQL Release Engineering Team

MySQL Connector/Node.js 8.0.11 GA has been released

MySQL Connector/Node.js is a new Node.js driver for use with the X DevAPI. This release, v8.0.11, is the first general availability release of the MySQL Connector/Node.js 8.0 series.

The X DevAPI enables application developers to write code that combines the strengths of the relational and document models using a modern, NoSQL-like syntax that does not assume previous experience writing traditional SQL.

MySQL Connector/Node.js can be downloaded through npm (see for details) or from

To learn more about how to write applications using the X DevAPI, see For more information about how the X DevAPI is implemented in MySQL Connector/Node.js, and its usage, see

Please note that the X DevAPI requires at least MySQL Server version 5.7.12 or higher with the X Plugin enabled. For general documentation about how to get started using MySQL as a document store, see

Changes in MySQL Connector/Node.js 8.0.11 (2018-04-19, General

Functionality Added or Changed

  • The protobuf.js library was replaced with the official google-protobuf npm package.
  • Added NOWAIT and SKIP_LOCKED support to the lockShared() and lockExclusive() methods. Example usage: lockShared(mysqlx.LockContention.SKIP_LOCKED).
  • Added the X DevAPI SHA256_MEMORY authentication mechanism.
  • Auto-generated document _id values generated by the MySQL server, introduced in MySQL Server 8.0.11, are now supported.

Bugs Fixed

  • Running a select query against a table containing BIGINT values and using those values as filtering criteria could fail to function. This was because those values were converted to JavaScript numbers when encoding the protobuf message, and lost precision since the maximum safe integer in JavaScript is 2^53 – 1. (Bug #27570761)
  • Row values from columns using the FLOAT type were not rounded according to the maximum number of displayable decimal digits defined by the schema. For example, a column with type FLOAT(3,2) containing a value of 1.23456789 would display as 1.2300000190734863 instead of the expected 1.23. (Bug #27570541)
  • Row values from columns using the BIT ( data type were decoded as their sign integer counterpart instead of unsigned values. For example, b’111′ was decoded as -4 instead of 7. (Bug #27570462)
  • Row values for columns of any type of UNSIGNED integer (TINYINT, SMALLINT, MEDIUMINT, INT or BIGINT) were being interpreted by the connector as their SIGNED integer value counterpart. (Bug #27570342)
  • The sort() method was added to the following operations: CollectionFind, CollectionRemove, and CollectionModify. (Bug #27429922)
  • While adding a document, the expression parser was rejecting valid escaped literally strings that constituted properties of the document, and it threw unexpected errors. (Bug #27429852)
  • Messages split into multiple fragments (either because they exceeded the MTU or the maximum size of V8 buffers) were improperly reconstructed and could not be decoded. This behavior would throw an error similar to “Uncaught SyntaxError: Unexpected token”. (Bug #27429429)
  • Several methods returned plain JavaScript objects that now return iterable arrays. Schema.getCollections() now returns an array of Collection instances, Schema.getTables() now returns an array of Table instances, and Session.getSchemas() now returns an array of Schema instances. (Bug #27294362, Bug #27221114)
  • The expression parser was executed every time a document was added but now requires mysqlx.expr() to be explicitly called. For example, before collection.add({ name: ‘foo’ }) would parse the “name” property. Now, to parse it, use collection.add({ name: mysqlx.expr(‘”foo”‘) }). (Bug #27177864)

Enjoy and thanks for the support!

MySQL Router 8.0.11 GA has been released

Dear MySQL users,

MySQL Router 8.0.11 is the first GA release for MySQL Router 8.0 series.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.11, see the “Generally Available (GA)
Releases” tab at Package
binaries are available for several platforms and also as a source code

Documentation for MySQL Router can be found at


Changes in MySQL Router 8.0.11 (2018-04-19,General Availability)

Bugs Fixed

* Some failed SQL queries executed during the bootstrap
process resulted in a generic "Unknown error" message instead of
reporting the original error message received from the MySQL
server. As a workaround, setting level=DEBUG during bootstrap
yielded these SQL errors. (Bug #27721898)

* Some unexpected errors from the MySQL server were not
shown during the Router bootstrap process. (Bug #27721834)

* Router failed to compile on Alpine Linux 3.6. (Bug

* Router's max_connect_errors option did not function in
v8.0.4. (Bug #27564958)

* Bootstrapping would only function if --bootstrap was the
first command-line argument. Now the argument order is
irrelevant. (Bug #25054974)

On behalf of Oracle MySQL Release Team
Nawaz Nazeer Ahamed

MySQL Connector/Java 5.1.46 GA has been released

Dear MySQL Users,

MySQL Connector/J 5.1.46, a maintenance release of the production 5.1
branch has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

MySQL Connector Java is available in source and binary form from the
Connector/J download pages at
and mirror sites as well as Maven-2 repositories.

MySQL Connector Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will shortly be available on
eDelivery (OSDC).

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

MySQL Connector/J 5.1.46 includes the following general bug fixes and
improvements, also available in more detail on

Changes in MySQL Connector/J 5.1.46 (2018-03-12)

Version 5.1.46 is a maintenance release of the production 5.1
branch. It is suitable for use with MySQL Server versions
5.5, 5.6, 5.7, and 8.0. It supports the Java Database
Connectivity (JDBC) 4.2 API.

Functionality Added or Changed

* Because Connector/J restricted TLS versions to v1.1 and
below by default when connecting to MySQL Community
Server 8.0 (which used to be compiled with yaSSL by
default and thus supporting only TLS v1.1 and below), it
failed to connect to to a MySQL 8.0.4 Community Server
(which has been compiled with OpenSSL by default and thus
supports TLS v1.2) that was configured to only allow TLS
v1.2 connections. TLS v1.2 is now enabled for connections
with MySQL Community Server 8.0.4 and later. (Bug

* The bundle for Connector/J 5.1 delivered by Oracle now
contains an additional jar package with the name
(mysql-connector-java-commercial-5.1.ver.jar for
commercial bundles). It is identical with the other jar
package with the original package named
(mysql-connector-java-commercial-5.1.ver-bin.jar for
commercial bundles), except for its more Maven-friendly
file name. (Bug #27231383)

* The lower bound for the connection property
packetDebugBufferSize has been changed to 1, to avoid the
connection errors that occur when the value is set to 0.
(Bug #26819691)

* For multi-host connections, when a MySQL Server was
configured with autocommit=0, Connection.getAutoCommit()
did not return the correct value. This was because
useLocalSessionState=true was assumed for multi-host
connections, which might not be the case, resulting thus
in inconsistent session states.
With this fix, by default, Connector/J executes some
extra queries in the connection synchronization process
to guarantee consistent session states between the client
and the server at any connection switch. This would mean,
however, that when none of the hosts are available during
an attempted server switch, an exception for closed
connection will be thrown immediately while, in earlier
Connector/J versions, there would be a connection error
thrown first before a closed connection error. Error
handling in some applications might need to be adjusted
Applications can skip the new session state
synchronization mechanism by having
useLocalSessionState=true. (Bug #26314325, Bug #86741)

* Connector/J now supports the new caching_sha2_password
authentication plugin for MySQL 8.0, which is the default
authentication plugin for MySQL 8.0.4 and later (see
Caching SHA-2 Pluggable Authentication
gable-authentication.html) for details).
To authenticate accounts with the caching_sha2_password
plugin, either a secure connection to the server using
reference-using-ssl.html) or an unencrypted connection
that supports password exchange using an RSA key pair
(enabled by setting one or both of the connecting
properties allowPublicKeyRetrieval and
serverRSAPublicKeyFile) must be used.
Because earlier versions of Connector/J 5.1 do not
support the caching_sha2_password authentication plugin
and therefore will not be able to connect to accounts
that authenticate with the new plugin (which might
include the root account created by default during a new
installation of a MySQL 8.0 Server), it is highly
recommended that you upgrade now to Connector/J 5.1.46,
to help ensure that your applications continue to work
smoothly with the latest MySQL 8.0 Server.

Bugs Fixed

* When Connector/J 5.1.44 or earlier connected to MySQL
5.7.20 or later, warnings are issued because Connector/J
used the deprecated system variables tx_isolation and
tx_read_only. These SQL-level warnings, returned from a
SHOW WARNINGS statement, might cause some applications to
throw errors and stop working. With this fix, the
deprecated variables are no longer used for MySQL 5.7.20
and later; also, to avoid similar issues, a SHOW WARNINGS
statement is no longer issued for the use of deprecated
variables. (Bug #27029657, Bug #88227)

* When the default database was not specified for a
connection, the connection attributes did not get stored
in the session_connect_attrs table in the Performance
Schema of the MySQL Server. (Bug #22362474, Bug #79612)

On Behalf of Oracle/MySQL Release Engineering Team
Hery Ramilison

Preparing your Community Connector for MySQL 8 – part 2 – SHA256

In part 1 of this series we looked at implementing support for the caching_sha2_password authentication plugin using the libmyqlclient C library.  This is possible for C based connectors or connectors that can make use of an external C library.  For some, this is not possible.  For example, Java and C# both function better if they don’t have to thunk out to an external library.  For these, implementing the MySQL client/server protocol natively is required.  This part 2 is about implementing support for the caching_sha2_password plugin natively.  It is expected that you already have a working connector and understand the client/server protocol.  For reference please internal documentation here.  This post will not attempt to always give you precise byte positions or counts.  For that please see the above linked internal documentation.

This blog post will not attempt to explain every aspect of implementing the connection phase of the client server protocol.   For help in implementing it please refer to

Initial Handshake

When initially connected, the server sends an initial handshake packet with lots of information.  Part of that information is the default authentication plugin that is set for the server.  Many connectors give the user the option of specifying an authentication plugin via a configuration or connection string option.  Doing this can eliminate a round trip during authentication.  However if you don’t do this or the user has not specified an authentication method, then attempting authentication using the default method is the way to go.

So a handshake response packet is now sent.  Part of this packet is the username, the “auth response”, and the plugin name.   Username is simple and the plugin name will be the name of the authentication plugin you received in the initial handshake packet.   By default starting with 8.0.4, that will be “caching_sha2_password” (assuming we are not switching to a different method).  The “auth response” part of the packet is the SHA256 scramble of the password.  This scramble uses the format

XOR(SHA256(PASSWORD), SHA256(SHA256(SHA256(PASSWORD)), seed_bytes))

Here the seed_bytes are the bytes originally passed to the plugin.

After sending the handshake response packet to the server, the server will respond with a packet.  There are four possible responses from the server:

  • Server sends a “More data” packet (first byte == 0x01) with the second byte = 0x03.  This will be followed by a normal OK packet.  This is the case when the user’s password is already in the server cache and authentication has succeeded.  We call this the “fast” authentication.
  • Server sends back an “error” packet.  This means the user’s password is in the cache but it doesn’t match what was given.
  • Server sends back an “auth switch” packet (first byte == 0xFE).  This means that the user who is trying to authenticate is using a different authentication plugin than the one specified and an auth switch cycle needs to happen.
  • Server sends back a “More data” packet (first byte == 0x01) with the second byte = 0x04.  This means that more data is needed to complete the authentication.  In the example of using “caching_sha2_password” this means that the users password is not in the server cache and the server is asking the client to send the user’s full password.  This is called the “full” authentication.

Full Authentication

When the server cache does not contain the password hash, the server asks for the full password so the cache can be populated.  This can be done in one of two ways:

  • Passing it in plain text if the connection is already secure using SSL/TLS.
  • Encrypting it with the servers public key if the connection is not secure.

Full Authentication via SSL/TLS

If the connection is already secure then all that is necessary is to pass the users password in clear text.  This is as simple as simply sending a single packet containing only the password as a zero terminated array of bytes.  The server will then respond with either an “Ok” packet if authentication was successful or an “Error” packet if not.

Full Authentication via RSA Key Exchange

If the connection is not already secure then passing the password in clear text is obviously not going to work.  This case is handled by the client encrypting the user’s password with the server’s public key and sending that back.  Here are the steps to accomplishing that.

  • In response to receiving the 0x01 0x04 packet from the server, the client has two choices.  The client could respond with a packet containing the single byte 0x02.  This requests the server send it’s public key.  This is considered somewhat insecure.  A better option if available would be for the client to have the server public key locally.  This would be stored in some implementation defined way.
  • If the client requested the server send the public key, the server will then respond with a “More data” packet containing the servers public key
  • The client then responds with the password encrypted with the servers public key. (see below for more details)
  • The server would then respond with either the Ok or Error packet.

Password Encryption (a closer look)

The password is “obfuscated” first by employing a rotating “xor” against the seed bytes that were given to the authentication plugin upon initial handshake.   Pseudocode for this might look like this:

Buffer would then be encrypted using the RSA public key the server passed to the client.  The resulting buffer would then be passed back to the server.

RSA Padding Change

It’s important to note that a incompatible change happened in server 8.0.5.  Prior to server 8.0.5 the encryption was done using RSA_PKCS1_PADDING.  With 8.0.5 it is done with RSA_PKCS1_OAEP_PADDING.  This means that if you have implemented support for this authentication scheme for servers prior to 8.0.5 you will need to update your connector to make this change.


I hope this blog has helped you understand a bit better how to implement this new security protocol into your product.  We continually strive to find new and better ways to help protect your data.  Please let us know if you have any questions or find any errors with this post!

MySQL Connector/C++ 8.0.7-rc has been released

Dear MySQL users,

MySQL Connector/C++ 8.0.7-rc is the release candidate (RC)
of the MySQL Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ applications using X DevAPI or plain C applications using

To learn more about how to write applications using X DevAPI, see
“X DevAPI User Guide”

and “X DevAPI Reference” at

For more information about using plain C XAPI see “XAPI Reference” at

For generic information on using Connector/C++ 8.0, see


Connector/C++ 8.0 requires MySQL Server version 8.0 or higher with
X Plugin enabled. For general documentation about how to get started
using MySQL as a document store, see “Using MySQL as a Document Store”

To download MySQL Connector/C++ 8.0.7-rc, see the “Development Releases”
tab at

Changes in MySQL Connector/C++ 8.0.7 (2018-02-26, Release

In addition to the new APIs introduced in MySQL Connector/C++
8.0 (X DevAPI and XAPI), Connector/C++ now also supports the
legacy API based on JDBC4. Applications written against the
JDBC4-based API of Connector/C++ 1.1 can be also compiled
with Connector/C++ 8.0, which is backward compatible with the
earlier version. Such code does not require the X Plugin and
can communicate with older versions of the MySQL Server using
the legacy protocol. This contrasts with X DevAPI and XAPI
applications, which expect MySQL Server 8.0.

The legacy API is implemented as a separate library with base
name mysqlcppconn as opposed to mysqlcppconn8 library
implementing the new APIs. For information about using the
legacy API, refer to the documentation at

* Deprecation and Removal Notes

* Security Notes

* X DevAPI and XAPI Notes

* Functionality Added or Changed

* Bugs Fixed

Deprecation and Removal Notes

* View and table DDL methods have been removed. It is
preferable that SQL statements be used for such
Removed X DevAPI methods:

Removed X DevAPI data types:

Removed XAPI functions:

Removed XAPI enumerations:

Removed XAPI macros:

Security Notes

* MySQL Connector/C++ now supports the
caching_sha2_password authentication plugin introduced in
MySQL 8.0 (see Caching SHA-2 Pluggable Authentication
with these limitations:

+ For applications that use X DevAPI or XAPI, only
encrypted (SSL) connections can be used to connect
to cached_sha2_password accounts. For non-SSL
connections, it is not possible to use
cached_sha2_password accounts.

+ For applications that use the legacy protocol, it is
not possible to make connections to
cached_sha2_password accounts in the following
o The connection is unencrypted (OPT_SSL_MODE is
o The server public key is given using the
"rsaKey" option and no RSA key exchange is used
(OPT_GET_SERVER_PUBLIC_KEY is set to false).
If RSA key exchange is enabled, the connection

X DevAPI and XAPI Notes

* It is now possible to use the Collection interface to
create and drop indexes on document collections.
X DevAPI example:
"fields": [
{ "field": "$.zip", "type": "TEXT(10)" },
{ "field": "$.count", "type": "INT UNSIGNED" }

"type": "SPATIAL",
"fields": [ { "field": "$.coords", "type": "GEOJSON", "srid": 3128
7 } ]


XAPI example:
ret = mysqlx_collection_create_index(coll, "idx",
"fields": [
{ "field": "$.zip", "type": "TEXT(10)" },
{ "field": "$.count", "type": "INT UNSIGNED" }

ret = mysqlx_collecton_create_index(coll, "loc",
"type": "SPATIAL",
"fields": [ { "field": "$.coords", "type": "GEOJSON", "srid": 3128
7 } ]

mysqlx_collection_drop_index(coll, "idx");

* It is now possible to use the Session interface to create
savepoints inside transactions and roll back a
transaction to a given savepoint. This interface supports
the operations provided by the SAVEPOINT, ROLLBACK TO
SAVEPOINT, and RELEASE SAVEPOINT statements. For more
information about these statements, see SAVEPOINT,
X DevAPI example:
string point1 = sess.setSavepoint();
sess.rollbackTo(point1);         // this also removes savepoint "point
string point3 = sess.setSavepoint();
sess.releaseSavepoint(point3);  // explicitly remove savepoint

XAPI example:
const char *point1 = mysqlx_savepoint_set(sess,NULL);
const char *point3 = mysqlx_savepoint_set(sess,NULL);

Functionality Added or Changed

* MySQL Connector/C++ now implements TLS connections using
the OpenSSL library. It is possible to build
Connector/C++ with OpenSSL or the bundled yaSSL
implementation of TLS. This is controlled by the WITH_SSL
CMake option, which takes these values: bundled (build
using bundled yaSSL code); system (build using system
OpenSSL library, with the location as detected by CMake);
path_name (build using OpenSSL library installed at the
named location). For more information, see

Bugs Fixed

* replaceOne() and similar methods did not correctly detect
document ID mismatches. (Bug #27246854)

* Calling bind() twice on the same parameter for complex
types resulted in empty values. (Bug #26962725)

On Behalf of the MySQL/Oracle Release Engineering Team,
Daniel Horecki

MySQL Router 8.0.4-rc has been released

Dear MySQL users,

MySQL Router 8.0.4-rc is the first release candidate for MySQL Router
8.0 series.

The MySQL Router is a new building block for high availability solutions
based on MySQL InnoDB clusters.

By taking advantage of the new Group Replication technology, and
combined with the MySQL Shell, InnoDB clusters provide an integrated
solution for high availability and scalability for InnoDB based MySQL
databases, that does not require advanced MySQL expertise.

The deployment of applications with high availability requirements is
greatly simplified by MySQL Router. MySQL client connections are
transparently routed to online members of a InnoDB cluster, with MySQL
server outages and cluster reconfigurations being automatically handled
by the Router.

To download MySQL Router 8.0.4-rc, see the “Development Releases” tab at Package binaries are available
for several platforms and also as a source code download.

Documentation for MySQL Router can be found at


Changes in MySQL Router 8.0.4 (2018-02-07, Release Candidate)

   Functionality Added or Changed

     * Bootstrapping now accepts the --config option and reads
       the [logger] level option's definition. For example, to enable
       bootstrap's debugging mode:
       level = DEBUG

       (Bug #27158098)

     * The default ttl metadata option (Time To Live, in
       seconds) changed from 300 to 5. (Bug #26990955, Bug #88140)

     * The new connect_timeout and read_timeout options were
       added. These are defined under the [DEFAULT] namespace and affect
       internal operations, such as metadata server connections. (Bug

     * Bootstrap now accepts any member of an InnoDB cluster and
       automatically finds and reconnects to a writable primary.  (Bug

     * The optional routing_strategy configuration option was
       added. The available values are first-available, next-available,
       round-robin, and round-robin-with-fallback.  Previously, these
       strategies were described as scheduling modes by the mode
       configuration option where the read-write mode defaults to the
       first-available strategy, and the read-only mode defaults to the
       round-robin strategy. This preserves previous behavior for these
       modes. (Bug #86261, Bug #26045094, Bug #25852803)

   Bugs Fixed

     * With logging_folder undefined during bootstrap, all logs
       were written to STDERR. Now, normal bootstrap logs are written to
       STDOUT and debug bootstrap logs are written to STDERR. (Bug

     * Errors were changed to warnings for the following
       conditions: when Router could not connect to a particular
       metadata server, and when Router could not update the default
       metadata cache replicaset. Under these conditions, Router does
       not stop running because there are multiple metadata servers and
       replicasets. (Bug #27226627)

     * Configuring MySQL Router with sockets would create a
       socket that was only accessible by the MySQL Router user.  (Bug
       #27179456, Bug #88667)

     * The commercial .deb packages were missing the
       mysqlrouter_plugin_info tool. (Bug #27122367)

     * The apt purge process did not remove the
       /var/{lib,log,run}/mysqlrouter directories. (Bug #26955232)

     * Bootstrapping would fail when connecting to a MySQL
       Server under high load if an associated bootstrap query took
       longer than 5 seconds. The 5 second read timeout was increased
       from 5 to 30. In addition, command line options were added to
       change the connect and read timeout values.  (Bug #26877946)

     * Improved error text when bootstrapping against a MySQL
       server 8.0 instance that was not part of InnoDB cluster.  (Bug

     * Router assumed that a resulting socket from accept()ing a
       socket would be always blocking. On Solaris and Windows this
       assumption is not valid, and this resulted in broken connections
       with large result sets. (Bug #26834769)

     * It was difficult to distinguish the "Too many
       connections" between MySQL Server and MySQL Router, so the Router
       variant now reads as "Too many connections to MySQL Router". (Bug

     * The bundled README.txt was missing Protobuf and Rapid
       JSON references. (Bug #25619654)

     * Some builds were missing the sample configuration file,
       including the Solaris and Oracle Linux binaries. (Bug #25530691)

     * Router would check IPv4 or IPv6 addresses, but not both.
       Now it goes through the list of addresses and first tries to bind
       to an IPv4 address and if it fails then it goes through the same
       address list and tries to bind to an IPv6 address. (Bug

     * The generated error message from passing in an empty file
       to --master-key-file (or using an empty mysqlrouter.key) was
       improved. (Bug #25111926)

     * Defining multiple logger sections in the configuration
       file would emit an unclear error. Defining multiple logger
       sections is not allowed. (Bug #25095565)

     * Where destinations=metadata-cache, the role attribute was
       not used or validated; only the mode configuration option was
       used. (Bug #25061854)

     * Failed bootstrap commands would leave a generated
       mysqlrouter.conf.tmp file on the system. (Bug #24930442)

     * On Ubuntu Linux, documentation related files were
       installed under both /usr/share/mysql-router/docs and
       /usr/share/doc/mysql-router. Now they are only installed under
       /usr/share/doc/mysql-router for community builds and
       /usr/share/doc/mysql-router-commercial for commercial builds.
       (Bug #24765509)

     * The maximum number of concurrent client connections was
       increased from about 500 to over 5000, a limit now dependent on
       the operation system. To achieve this, select() based fd event
       calls were replaced by poll() (or WSAPoll() on Windows). (Bug
       #22661705, Bug #80260)

     * The --ssl-key and --ssl-cert optional bootstrap
       command-line options were added. They directly use their MySQL
       client's counterparts, and specify the client-side certificate
       and private key to facilitate client-side authentication. This is
       useful when the root account used during bootstrap was created
       with REQUIRE X509, which requires the client to authenticate
       itself when logging in.

On behalf of Oracle MySQL Release Team
Nawaz Nazeer Ahamed