Install Mysql Connector Java Ubuntu 20.04
Halima Wallace
I am installing Ignition 8.1.xx on a Red Hat Enterprise Linux 8.5 server. When I attempt to make a database connection to my MySQL database I get an error that connector files are missing. I believe the missing file is mysql-connector-java-8.0.29-1.e18.noarch.rpm. When I proceed to install this file I get the following error:
So I replaced the mysql-connector-java file with an older version (8.0.15), but when I go to CF admin settings page and look at CF Server Java Class Path, it still lists the newer version (8.0.25). And I did confirm the location of the file. I have restarted CommandBox and even my laptop, just in case.
I started a fresh Ambari installation on Ubuntu 16 following -2.6.2.0/bk_ambari-installation/content/ch_Getting_R.... All options are using default values and it completed successfully. In the process, it did not ask for mysql connector installation.
Based on my previous questions, it is pointing to missing mysql connector. I followed -2.6.2.0/bk_ambari-administration/content/using_amba..., downloaded and installed connector. But at step #2, I ran into following error. What should I do to make mysql running?
MariaDB Connector/J is a Type 4 JDBC driver. It was developed specifically asa lightweight JDBC connector for use with MariaDB and MySQL database servers.It was originally based on the Drizzle JDBC code with numerous additions andbug fixes.
The following subsections show the formatting of JDBC connection strings forMariaDB and MySQL database servers. Additionally, sample code is provided thatdemonstrates how to connect to one of these servers and create a table.
The preferred way to get a connection with MariaDB Connector/J is to use the DriverManager class.When the DriverManager class is used to locate and load MariaDB Connector/J, the application needs no further configuration. The DriverManager class will automatically load MariaDB Connector/J and allow it to be used in the same way as any other JDBC driver.
MariaDB Connector/J 3.0 only accepts jdbc:mariadb: as the protocol in connection strings by default. When both MariaDB Connector/J and the MySQL drivers are found in the class-path, using jdbc:mariadb: as the protocol helps to ensure that Java chooses MariaDB Connector/J.
driver 3.0 is a complete rewrite of the connector. Specific support for aurora has not been implemented in 3.0, since it relies on pipelining. Aurora is not compatible with pipelining.Issues for Aurora were piling up without the community proposing any PR for them and without access for us to test those modifications. (2.x version has a 5 years support).
GSSAPI in windows isn't well supported in java, causing recurrent issues. Since 3.1, waffle-jna is marked as a dependency to provide good GSSAPI support without problems. This has the drawback to make connector and dependencies to a size of around 4Mb.
By default, the connector adopts the JVM's default time zone. If the client and server reside in different time zones, it's recommended to configure the connection time zone to match the JVM's default by setting forceConnectionTimeZoneToSession to true.This ensures proper operation of time functions.
Due to its wider range, DATETIME is sometimes mistakenly used to store a specific point in time. While this might work if the client and server share the same time zone, it creates problems when they differ.
While using DATETIME instead of TIMESTAMP is generally discouraged, a specific combination of settings ("preserveInstants=true&connectionTimeZone=SERVER") can force all Java Timestamp exchanges to be converted to the connection's time zone during storage and retrieval. However, this approach is not recommended for long-term solutions.
The MariaDB Connector/J versions before 3.4 offered a single "timezone" option. While this functionality remains compatible, it's now separated into two distinct settings: connectionTimeZone and forceConnectionTimeZoneToSession. Here's a breakdown of how the old option translates to the new ones:"timezone=America/Los_Angeles" is equivalent to "connectionTimeZone=America/Los_Angeles&forceConnectionTimeZone=true
The fastest way to load lots of data is using LOAD DATA INFILE.
However, using "LOAD DATA LOCAL INFILE" (ie: loading a file from the client) may be a security problem if someone can execute a query from the client, he can have access to any file on the client (according to the rights of the user running the client process).
To avoid using too much memory, rather use Statement.setFetchSize(int numberOfRowInMemory) to indicate the number of rows that will be stored in memory
Example :
using Statement.setFetchSize(1000) indicates that 1000 rows will be stored in memory.
So, when the query has executed, 1000 rows will be in memory. After 1000 ResultSet.next(), the next 1000 rows will be stored in memory, and so on.
If another query is run on same connection while the resultset has not been completly read, the connector will fetch all remaining rows before executing the query. This can lead to still needing lots of memory. Recommendation is then to use another connection for simultaneous operations.
Note that the server usually expects clients to read off the result set relatively quickly. The net_write_timeout server variable controls this behavior (defaults to 60s).If you don't expect results to be handled in this amount of time there is a different possibility:
If another query is executed on the same connection when a streaming resultset has not been fully read, the connector will put the whole remaining streaming resultset in memory in order to execute the next query. This can lead to OutOfMemoryError if not handled.
Before version 1.4.0, the only accepted value for fetch size was Statement.setFetchSize(Integer.MIN_VALUE) (equivalent to Statement.setFetchSize(1)). This value is still accepted for compatilibity reasons but rather use Statement.setFetchSize(1), since according to JDBC the value must be >= 0.
The driver uses server prepared statements as a standard to communicate with the database (since 1.3.0). If the "allowMultiQueries" options are set to true, the driver will only use text protocol. Prepared statements (parameter substitution) is handled by the driver, on the client side.
To use this credential authentication, com.amazonaws:aws-java-sdk-rds dependency must be registred in classpath.Implementation use SDK DefaultAWSCredentialsProviderChain and DefaultAwsRegionProviderChain to get IAM credential and region.see DefaultAWSCredentialsProviderChain and DefaultAwsRegionProviderChain to check how those information can be retrieved (environment variable / system properties, files, ...)
New authentication plugins can be created implementing interface org.mariadb.jdbc.authentication.AuthenticationPlugin, and listing new plugin in a META-INF/services/org.mariadb.jdbc.authentication.AuthenticationPlugin file.
Custom SSL implementation can be used implementing A connection to a server initially creates a socket. When set, SSL socket is layered over this existing socket. Implementing org.mariadb.jdbc.tls.TlsSocketPlugin permit to provide custom SSL implementation for example create a new HostnameVerifier implementation.
Most of the time this will be caused by reading a query that has a large resultset; the server usually expects clients to read off the result set relatively quickly. The net_write_timeout server variable controls this behavior (defaults to 60s). If the client doesn't read the whole resultset in that amount of time, the server will discard the connection.If you don't expect results to be handled in this amount of time there is another possibility:
Connection.isValid() is a good approach. Connection.isValid() is doing a ping (ping in mysql protocol, not network ping). Connection pool using JDBC4 Validation are using automatically this Connection.isValid()
My Ansible/Rundeck host is an Ubuntu 20.04 LTS system. I installed Ansible to tinker and then installed Rundeck. Once I was able to get the two talking and working properly (in my mind), I thought it would be best to move Rundeck to a production level DB engine instead of H2. I installed MySQL on the same host and setup the DB and the DB user as directed in the Rundeck docs. I then modified the RD properties file as the same document instructs but I keep getting a failure to connect to the database.
I then downloaded the Oracle MySQL jdbc driver and placed it in the var/lib/rundeck/lib folder and changed the driver class name in the properties file and then I received my but that could not connect. I was able to detect in the system.log output: ' Unable to load class: com.mysql.jc.jdbc.Driver from ClassLoader:org.springframework.boot.loader.'. Obviously the MySQL jdbc driver is not being loaded or possibly found at all. I placed the file in /var/lib/rundeck/lib. Do I need to give the file any special permissions or should it be named something specific. I used wget to download it while in Ubuntu. The file name is mysql-connector-java-8.0.22.jar and it transferred without any issue.
At this point I am back on H2 and I am too much of a Linux novice to understand what the issue may be. Can anyone kindly point me in a direction that helps as the Rundeck docks for using a MySQL DB seem to either be old or missing some content as a lot of the searches I have made on trying to resolve the issue directs me to perform things slight differently or all new commands that the Rundeck docs don't even mention.
MariaDB connector was my fault. I was trying to use com.mariadb.jdbc.Driver. org works fine. Also confirmed my suspicions - mariadb-java-client-1.5.7.jar can be located wherever wanted. I keep it in my home directory. Also confirmed MariaDB works with SQL Workbench/J (I use this more than any other). Good news as there is a lack of good tools (my opinion) for it in Linux.
On Linux Debian copy this jar file into /usr/share/java/. (I had a hard time finding where to copy it to. Another post suggested this location. Perhaps you could search your system for jar files. Or perhaps someone else can suggest how to determine where to put it.
d3342ee215