Background # A critical vulnerability CVE-2021-44228 in the Apache Log4j logging library was disclosed on Dec 9. The project provided release 2.15.0 with a patch that mitigates the impact of this CVE. It was quickly found that the initial patch was insufficient, and an additional CVE CVE-2021-45046 followed. This has been fixed in release 2.16.0. Who is affected? # The bulk of vitess code is in golang, and is unaffected by these vulnerabilities.
10 Older Entries »
Per Oracle’s Lifetime Support policy, as of Feb 9th, 2021, MySQL Connector/J 5.1 series is covered under Oracle Sustaining Support. Downloadable binaries can be found in the MySQL Products Archives and in the Maven Central Repository.
MySQL Connector/J 5.1.49 has been the last release of Connector/J 5.1 series.
It is time to move on. Users are encouraged to upgrade to MySQL Connector/J 8.0 series which provides the same features as Connector/J 5.1 and a lot more, including a brand new date/time handling support, introduced in version 8.0.23, and the X DevAPI that empowers the MySQL Document Store.
We like to hear from you. Please join …[Read more]
Introduction Welcome to a new issue of the High-Performance Java Persistence Newsletter in which we share articles, videos, workshops, and StackOverflow answers that are very relevant to any developer who interacts with a database system using Java. Articles From version 2.12, Percona PMM uses Victoria Metrics instead of Prometheus. Victoria Metrics provides better disk I/0 utilization and less memory usage. For more details about this change and its benefits, check out this article. By default, the MySQL JDBC Driver only emulates prepared statements. If you wonder whether server-side prepared statements perform better... Read More
The post High-Performance Java Persistence Newsletter, Issue 22 appeared first on …[Read more]
X Protocol traffic compression is available on MySQL Server since version 8.0.19. A connector that also supports compression on its end can leverage this feature and reduce the byte streams that are exchanged with the Server.
By default, connections to a MySQL server are uncompressed, thus permitting exchanging data with a client or connector that doesn’t support compression. However, given a client or connector that also supports compression, it is recommended that client and server negotiate the connection compression by default. If this negotiation concludes successfully, both ends can then compress the data they send.
Compression at this level allows reducing the amount of bytes exchanged over the network, but at the cost of additional CPU resources required to run data inflate and deflate operations. The benefits of compression, therefore, occur primarily on low network bandwidth. One can assess the gain or loss due to the …[Read more]
In April, when I updated from MySQL 8.0.17 to MySQL 8.0.19, I
found that my Java connection example failed. That’s because of a
change in the JDBC driver, which I blogged about then. Starting yesterday, I
began updating a base Fedora 30 configuration again to MySQL
8.0.20. I wrote a testing program for the Java JDBC file last
time, and when I ran it this time it told me that I didn’t have
the JDBC driver installed, or in the
Java diagnostic script,
the following error message:
Error: Could not find or load main class MySQLDriver
The Java JDBC test program code is in the prior post. It simply loads the user, password, database, host, and port statically for my student …[Read more]
It’s the in-between term time and we’re all stuck at home. I decided to update the image for my Fedora 30 virtual machine. I had a work around to the update issue that I had encountered last October in Bug #96969 but it was not required with the current version. However, after updating from MySQL 8.0.17 to MySQL 8.0.19, I found that my Java connection example failed.
$CLASSPATH value was correct:
The first error that I got was the my reference to MySQL JDBC driver was incorrect. The error message is quite clear:
Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary. Cannot connect to database server: The server time zone …[Read more]
Ran into an interesting situation trying to configure a MySQL JDBC driver to connect over TLS (though the driver may call it SSL, TLS is the name for more recent versions of the protocol).
The error I was getting was pretty generic:
Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
With the relevant parts of the stacktrace, also being non helpful:
at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:174) at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:64) at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:835) at com.mysql.cj.jdbc.ConnectionImpl.(ConnectionImpl.java:455) at com.mysql.cj.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:240) at …[Read more]
The Question Recently, a customer asked us:
Why would heavy disk IO cause the Tungsten Manager and not MySQL to be starved of resources?
For example, we saw the following in the Manager log file
2019/06/03 00:50:30 | Pinging the JVM took 29 seconds to respond. 2019/06/03 00:50:30 | Pinging the JVM took 25 seconds to respond. 2019/06/03 00:50:30 | Pinging the JVM took 21 seconds to respond. 2019/06/03 00:50:30 | Pinging the JVM took 16 seconds to respond. 2019/06/03 00:50:30 | Pinging the JVM took 12 seconds to respond. 2019/06/03 00:50:30 | Pinging the JVM took 8 seconds to respond.
The Answer Why a Java application might be slow or freezing
The answer is that if a filesystem is busy being written to by another process, the background I/O will cause the Java JVM garbage collection (GC) to pause.
This problem is not specific to Continuent Tungsten …[Read more]
Dear MySQL users,
MySQL Connector/J Version 8.0.15 is the GA release of the
branch 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,
described in more detail on
As always, we recommend that you check the “CHANGES” file in
download archive to be aware of changes in behavior that might affect
To download MySQL Connector/J 8.0.15 GA, see the “Generally
(GA) Releases” tab at …
10 Older Entries »