MySQL Connector/ODBC 8.0.17 has been released

Dear MySQL users,

MySQL Connector/ODBC 8.0.17 is a new version in the MySQL Connector/ODBC 8.0 series,the ODBC driver for the MySQL Server.

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 the latest MySQL server version 8.0.

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 out for binary types only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode driver only).

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

Enjoy and thanks for the support!

Changes in MySQL Connector/ODBC 8.0.17  (2019-07-22, General Availability)

Functionality Added or Changed

     * and files were created for the convenience of git users. These files are not distributed with binaries, whereas README.txt remains distributed.

Bugs Fixed

     * The myodbc-installer command line utility did not display all DSN options. (Bug #29753227)

     * On Windows, building and installing from source could yield a binary that would not execute due to a case-sensitivity issue in the CMake logic. (Bug #29210040)

On Behalf of Oracle/MySQL Release Engineering Team,

Hery Ramilison 

MySQL Connector/ODBC 8.0.14 has been released

Dear MySQL users,

MySQL Connector/ODBC 8.0.14 is a new version in the MySQL Connector/ODBC 8.0 series,
the ODBC driver for the MySQL Server.

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).

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.14 (2019-01-21, General Availability)

Functionality Added or Changed

* A new ENABLE_LOCAL_INFILE connection option was added to
the connection string, DSN, and GUI. Disabled by default,
set ENABLE_LOCAL_INFILE=1 to enable LOAD DATA operations.
This toggles the MYSQL_OPT_LOCAL_INFILE mysql_options()
The connection string overrides the DSN value if both are

* MySQL Connector/ODBC is now compatible with MSVC 2017,
while retaining compatibility with MSVC 2015:

+ Previously, Connector/ODBC binary distributions were
compatible with projects built using MSVC 2015.
Binary distributions now are compatible with
projects built using MSVC 2017 or 2015.

+ Previously, Connector/ODBC source distributions
could be built using MSVC 2015. Source distributions
now can be built using MSVC 2017 or 2015.

+ Previously, the MSI installer accepted the Visual
C++ Redistributable for Visual Studio 2015. The MSI
installer now accepts the Visual C++ Redistributable
for Visual Studio 2017 or 2015.

* Two informative text files were added: INFO_BIN contains
information about the build environment used to produce
the distribution, and INFO_SRC provides information about
the product version and the source repository from which
the distribution was produced. Source distributions
include the INFO_SRC file only.

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

MySQL Connector/Node.js 8.0.13 has been released

Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.13, is a maintenance 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
8.0 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.13 (2018-10-22, General availability)

Functionality Added or Changed

* To go with the existing asynchronous
mysqlx.getSession(conn_str) method, a new synchronous
mysqlx.getClient(conn_str, options) method was added that
creates a connection pool handler that provides an
asynchronous getSession() method to create and retrieve
connections from the pool. The collection pooling options

+ enabled: enables or disables connection pooling;
boolean and defaults to true.

+ maxSize: maximum number of connections available in
the pool; positive integer and defaults to 25.

+ maxIdleTime: maximum number of milliseconds a
connection can be idle in the queue before being
closed; integer >= 0 and defaults to 0 (infinite).

+ queueTimeout: maximum number of milliseconds a
request will wait for a connection to become
available; integer >= 0 and defaults to 0
This is different than connectTimeout that’s used
for non-pooling. In a pooling scenario, there might
already be connections in the pool and queueTimeout
controls how long to wait for a connection in the
Example usage:
var mysqlx = require(‘@mysql/xdevapi’)
var client = mysqlx.getClient(
{ user: ‘root’, host: ‘localhost’, port: 33060 },
{ pooling: { enabled: true, maxIdleTime: 5000, maxSize: 25, queueTimeout: 20000 } }

.then(session => {
return session.close() // the connection becomes idle in the client pool
.then(() => {
return client.getSession()
.then(session => {
return client.close() // closes all connections and destroys the pool

Closing a session attached to the pool makes the
connection available in the pool for subsequent
getSession() calls, while closing (destroying) the pool
effectively closes all server connections.

* Added a connection timeout query parameter. This defines
the length of time (milliseconds) the client waits for a
MySQL server to become available in the given network
addresses. It was added to both the mysqlx.getSession()
(non-pooling sessions) and mysqlx.getClient() (pooling
sessions) interfaces. This option defaults to 10000 (10
seconds). The value 0 disables the timeout so the client
will wait until the underlying socket (platform
dependent) times out.
Similar to other option formatting rules, this option
defined as connection-timeout (kebab-case) for URI
definitions and connectionTimeout (camelCase) for plain
JavaScript configuration objects.
Example usage:
const mysqlx = require(‘@mysql/xdevapi’);
var client = mysqlx.getClient(‘root@localhost?connect-timeout=5000’)
.catch(err => {
console.log(err.message) // “Connection attempt to the server was aborted. Timeout of 5000 ms was exceeded.”

// Or

const mysqlx = require(‘@mysql/xdevapi’);
var client = mysqlx.getClient(‘mysqlx://root:passwd@[localhost:33060,]?connect-timeout=5000’)
.catch(err => {
// connection could not be established after 10 seconds (5 seconds for each server)
console.log(err.message); // All server connection attempts we re aborted. Timeout of 5000 ms was exceeded for each selected server.

In a multi-host scenario, the connect-timeout value
applies to each individual host.

Bugs Fixed

* Improved the handling of X Protocol global notices by
properly logging and then ignoring non-fatal errors, and
making the connection unusable for subsequent operations
in the case of a fatal error. (Bug #28653781)

* Calling getCollationName() on non-textual fields, such as
INT, threw the following error “TypeError: Cannot read
property ‘collation’ of undefined”. (Bug #28608923)

* The fields() method did not function with valid
expressions generated by the expr() method. (Bug

* The returned Session.inspect() object now includes the
‘user’ property in addition to the ‘dbUser’ property but
containing the same value. (Bug #28362115)

On Behalf of the MySQL/Oracle Release Engineering Team,
Hery Ramilison

MySQL Connector/J 8.0.12 has been released

Dear MySQL users,

MySQL Connector/J Version 8.0.12 is the second GA release of the 8.0 branch of MySQL Connector/J. 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, 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.12 GA, see the “Generally Available (GA)
Releases” tab at


Changes in MySQL Connector/J 8.0.12 (2018-07-27, General Availability)

   Version 8.0.12 is the latest 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.

     * Functionality Added or Changed

     * Bugs Fixed 

Functionality Added or Changed
     * X DevAPI: The following changes have been made to the API:
          + Removed ModifyStatement.arrayDelete() and ModifyStatement.merge().
          + Renamed Colletion.find().limit().skip() to Colletion.find().limit().offset().
          + To simplify the class hierarchy and to have the class names reflect better
            the classes' functions, the following changes have been made:
               o The FindParams class has been renamed to FilterParams 
               o The AbstractFindParams class has been renamed to AbstractFilterParams 
               o The DocFindParams class has been renamed to DocFilterParams 
               o The TableFindParams class has been renamed to TableFilterParams
            Notice that the methods in the original FilterParams class have been moved under
            the new AbstractFilterParams class.
       (Bug #28027459)

     * X DevAPI: Connector/J now uses synchronous client sockets ( by 
       default to communicate with MySQL servers for X Protocol connections. While
       asynchronous sockets can still be used by setting the connection property
       xdevapi.useAsyncProtocol=true, this is not recommended, as it might result in
       performance degradation for Connector/J. (Bug #27522054)

     * X DevAPI: Connector/J now gives provision for the use of a custom socket
       factory for  X Protocol connections to MySQL Servers using Unix domain sockets. 
       See Section 6.8, "Connecting Using Unix Domain Sockets" for details.

     * Connector/J now retrieves the MySQL keyword list from the INFORMATION_SCHEMA.KEYWORDS
       (  table on the MySQL
       server when a connection session is established. The list can then be accessed by
       calling DatabaseMetaData.getSQLKeywords().

     * To simplify the code, the ReadableProperty and ModifiableProperty classes have
       been consolidated into the RuntimeProperty class.

Bugs Fixed

     * X DevAPI: When creating an X DevAPI session using a Properties map instead of a
       connection string, referring to property keys like host, port, and protocol in
       lowercase caused a NullPointerException. With the fix, both upper and lower
       cases can now be used. (Bug#27652379)

     * X DevAPI: When using the getConnection() method with the mysqlx: scheme in the
       connection URL, Connector/J returned an ordinary JDBC connection instead of an
       X-Protocol connection. (Bug #26089880)

     * If wait_timeout was set on the server and the Connector/J had the connection
       property interactiveClient=false, or if interactive_timeout was set on the
       server and Connector/J had the connection property interactiveClient=true, a
       connection is invalidated when it has idled for a longer time than the set timeout.
       When such a timeout occurred, Connector/J threw a CJCommunicationsException,
       without indicating it was a timeout. With this fix, the error message returned
       explains the issue and suggests how to avoid it. (Bug#27977617, Bug #90753)

     * When an application tried to connect to a non-MySQL database through some
      JDBC driver and Connector/J happened to be on the class path also, Connector/J
      threw a SQLNonTransientConnectionException, which prevented the application from
      connecting to its database. With this fix, Connector/J returns null whenever a
      connection string does not start with jdbc:mysql: or mysqlx:, so connections to
      non-MySQL databases are not blocked. (Bug#26724154, Bug #87600)

     * A wasNull() call on a ResultSet did not return the proper value unless
       AbstractResultsetRow.getNull() or AbstractResultsetRow.getValueFromByte() was
       called before. This caused data loss when Connector/J was used with frameworks like
       Hibernate, which rely on wasNull() calls to properly retrieve data. With this fix,
       wasNull() returns a correct value as long as some getter method has been called
       before on the ResultSet. (Bug #25924324, Bug#85941)

On Behalf of Oracle/MySQL Release Engineering Team
Prashant Tekriwal

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

MySQL X DevAPI 8.0.3 for PHP is here!

Dear MySQL users,

I’m glad to announce that MySQL X DevAPI extension for PHP 8.0.3 has been recently released!

If for some reason you don’t know what this is all about, then in short the MySQL X DevAPI for PHP add support for the new X DevAPI in PHP, and it’s released as an extension to the language. The X DevAPI enables application developers to write code that combines the strengths of the relational and document models –MySQL as a Document Store– using a modern NoSQL-like syntax that does not assume previous experience writing traditional SQL.

For general documentation about how to get started using MySQL as a document store, see “Using MySQL as a Document Store”.

Download the extension.

Depending on your operating system and working environment, you can download the extensio from:

  • Direct link to the mysql_devapi extension pecl web page, here.
  • On Fedor-ish Linux system, use the Remi’s repo.
  • Clone the source code repo, here.

Further instruction on how to install the extension with samples are included in the readme script and documentation.

This new release contains many bug fixes, refactoring’s and improvements that are a step forward in our work to improve the quality of the code base and thus of the extension itself, beside the minor tasks we were able to deliver some big features:

Support for Array or Object “contains” operator:

New CONTAINS and NOT_CONTAINS operators introduced in any expression valid in CRUD operations. They are different from the IN operator, in that IN works with SQL and requires a set of literals at the right side. CONTAINS should accept JSON values at the left and right sides of the operator,including expressions that generate a JSON value.
Example (Where $coll is a Column object):

New API’s: getOne, removeOne, replaceOne, addOrReplaceOne:

This extension is specific to Collections. These are commands that operate at a single document level, unlike the other CRUD commands that operate on all documents that match a filter the following collection commands are introduced as a set of direct-execution complementary operations that reference documented by id, as opposed to a free-form expression.

When working with small documents (majority of the time), the simplest and easiest way to change a certain document is to use a load/modify/save pattern:

New row locking mechanism for Crud.Find / Table.Select

The MySQL SELECT statement supports now locking matching rows, for reads and for writes (SELECT … FOR UPDATE or SELECT … LOCK IN SHARE MODE).

The find() CRUD method is extended to support this feature, allowing safe, transactional document updates on collections. Transaction support is an important MySQL differentiator compared to other NoSQL databases. Example:

Client A execute:

Client B execute:

Then Client A commits:

And finally Client B can continue:

Support for the new MySQL Server 8.x, including fixes for phpize build.

Large refactorings and fixes where made by the team to allow this PHP extension to fully support he new MySQL server 8.x, also the problems with the phpize build are now solved and we’re happy to deliver a rock solid release with plenty of support for the new MySQL’s.

Thanks for reading,

On behalf of the MySQL/Oracle X DevAPI for PHP Team, Filip Janiszewski

Simplified Client and Connector Versioning

Here at MySQL we are constantly improving both our servers and our client software by making things simple to use and understand.  An area where we want to simplify things is around the version number we use for various MySQL client, connector, and other applications like Workbench, MySQL Enterprise Backup, etc.


  • We want to make sure our users easily know which version of a connector or client works with which server version(s).
  • We want to deliver support for new server features during the server DMR phase without disrupting the GA versions of the connectors.

Which Connector Version To Use?

MySQL connectors (our client libraries — Connector/C, Connector/J, Connector/Net, etc) and other clients (tools and applications — MySQL Shell, MySQL Enterprise Backup, etc) will generally release more often than the server.  Relative to upgrading a set of servers in an enterprise, upgrading a client is normally quite simple.

Because of this rapid versioning of clients we have historically not tied the client version to the server version.  In addition to that we’ve changed the server versioning as of MySQL 8.0 to increment just the first digit for each major release.  After 8 comes 9, etc.

So you may see that the current versions of some client libraries are all over the place – 6.9 for Connector/Net, 5.1 for Connector/J, 2.1 for Connector/Python, or 4.1 for MySQL Enterprise Backup.  As you can see these version numbers do not relate to the server version at all.  We think this is confusing and with the recent server version change we could simplify things for clients, connectors, and applications.

Note:  In some cases we tried to make this easier by having a policy that all our support client libraries must support all servers that are still supported, but then there are other clients like MySQL Enterprise Manager where that’s not the case.

Challenges – DMRs and Testing Out New Server Features

The server team provides pre-release versions of the server available for testing out new features.  These releases are called DMR or “Development Milestone Release”.  While many of the new server features are transparent to client libraries, some require client library updates like new collations or new security measures.

When server changes affect clients users ask how can they try out the new features?   What connector or client version should they use?

And, features appearing in server DMR releases can change.  They are, after all, in development so adding support for pre-release features that can change into a GA connector is really a no-go.  So we need a  way to make new server features available to connectors and clients without disrupting the normal feature cycle of the clients.

Solving – New Simplified Versioning Methods for Clients

To address these issues beginning with the 8.0 server GA release, all of our connectors will synchronize the first digit of their version number with the server.   This means that MySQL Server 8.0 will go GA alongside 8.0 versions of each of our connectors.

Now, it’s easy to know which version of a client you should use – the first version number should match (starting with 8.x.x releases).

  • For Connectors – Using MySQL 8.0 then any of our MySQL connectors 8.0 or later will fit the bill!  Does this mean that older connectors will not work with MySQL 8.0?  Not necessarily!  However, older connectors might not be quite as compatible and will certainly not support many of the new features.
  • Other client tools and application – Will also go to 8.0 versions – MySQL Shell 8.0, MySQL Workbench 8.0, MySQL Enterprise Backup 8.0, etc.

As new MySQL Server DMR releases come out you can expect to see corresponding clients to help you try out the new features in both the client and the server.

We see the change as an opportunity to really clarify our product offerings using the version number and deliver a much more unified experience.  Clients will still version frequently so you’ll see some clients move ahead with 8.1 and 8.2 versions but that first digit 8 will still tell  you that it will work perfectly with MySQL Server 8.0

We’ll have more to say on this in the coming weeks!  Please let us know if you have any questions!

MySQL community recognition

On behalf of myself and the MySQL Engineering team, I’d like to thank everyone for naming Oracle the Corporate Contributor of the year at the MySQL Community awards ceremony at Percona Live 2014.

I’d also like to thank everyone who have come up to me and my fellow colleagues in person to thank us for the great work they have seen in MySQL 5.6 as well as 5.7. I only wish that more people in the MySQL Engineering team would be able to share that experience.

Therefore I cannot stress enough how important it is for my team to hear such positive feedback through talks, blogs, and tweets. Thank you for doing so, and please continue sharing your positive experience with MySQL openly. Why not read about the latest mysql engineering work and leave a comment on, it is a huge motivator.


Announcing new Yum repositories for MySQL

The MySQL Engineering Team at Oracle is excited to announce availability of Yum repositories for MySQL, making new releases of MySQL Database and related products easily accessible using Yum.  This initial release is focused on EL6-based distros as well as Fedora 18 and 19, and provides easy access to the most recent GA releases of our most popular products:

  • MySQL Database 5.6
  • MySQL Workbench 6.0
  • MySQL Connector/ODBC 5.2

We expect to expand this in the future to offer additional MySQL products and versions using these repositories, as well as repositories for additional Linux distributions.

This effort benefits both end users and Linux distributions.  Users will have additional choice in deploying specific versions of MySQL products using their favored package manager, while Oracle helps reduce overhead in packaging MySQL for specific distributions.  For users, the benefits are:

  • Ability to get MySQL components not yet packaged by their Linux distro.
  • Access to the latest and greatest versions of MySQL, even if they have not yet been adopted by their Linux distro.
  • Packages of MySQL products supported by Oracle.
  • Easy early access to pre-GA product releases, such as MySQL 5.7 Development Milestone Releases.

Equally important in driving this effort is our continued and expanding commitment to Linux distributions.  For this audience, the key benefits are:

  • Increased attention to packaging needs and concerns at Oracle means fewer opportunities for changes to be introduced which cause downstream packaging problems without awareness first at Oracle.
  • Maintainers have access to our packages as a template for solutions to packaging issues.
  • Oracle will have increased, distribution-specific experience and knowledge to draw upon in support of maintainer requests.
  • Packaging work will start before product GA at Oracle, allowing packaging to mature concurrently with the product it supports.

We’re excited to get MySQL 5.6 – the best release of MySQL Database ever – into the hands of more users, and to invest more in supporting maintainers in their efforts to package MySQL products for use within their Linux distributions.  These packages have been extensively tested internally, fully supported, and install fully tested and supported MySQL products.  Listed below are several resources you may find useful in deploying MySQL using the Yum repositories:

Please let us know about your experiences with these new repositories, as well as any suggestions you may have to improve the experience.  We welcome feedback – both bug reports and feature requests – via (there is a new “MySQL Repositories” category).

Also have a look at Norvald’s blog post documenting the team’s work producing these packages

Join us at MySQL Connect

I’m excited about this year’s MySQL Connect in San Francisco. It’s bigger than ever, with 3 days of sessions, tutorials, and hands on labs.  We have more MySQL engineers going there than ever before. Looking at the keynote we are preparing, we have a lot of great news, and exciting benchmark numbers to share.

If you have a chance, make sure you join us this year. Learn about the latest MySQL engineering development, and use this opportunity to talk to the MySQL engineers themselves.

Hope to see you there, Tomas