So I tried it, and it works. Here's some notes.
This is going to be a small blurb, on what I did to get this working.
Nothing out of the ordinary, really.And of course allow the user accounts to access mariadb remotely over the network.
Attention! I'm only doing this locally on a testing server! It's not a great idea to run mariadb connections remotely if you do not have to.
Just decided to do a followup on Adding MariaDB JDBC Connector to Payara 51.
I wanted to see if it was possibly very easy to do this using the command line.
The syntax:
Note the following:
Let's test it!
In case you wish to delete it, try:
Hello, again!
This is just a small blog post on how to backup and restore a MariaDB server, without using MysqlDump, but by directly copying the files in /var/lib/mysql.
First of course we need to shutdown mariadb.
Copying files:
When putting things back, things start to go wrong1.
Copying the files to a new host, causes this:
So, if the below code works, than SELinux is causing the issue:
Now you added mysql_t to permissive, as shown by the below printout:
Turning it back to enforcing, means running:
We need to relabel the new /var/lib/mysql directory:
Checking the current file contexts:
I need to check out MariaBackup2 3, as a better solution for creating backups compared to mysqldump.
I ran into some issues, and I thought I'd document them here.
So changed my persistence.xml and added:
Also:
As the vendor name was not detected, eclipselink switched to a default implementation. The default implementation requires SEQUENCES for the IDENTITY definition.
It turns out the MariaDB implementation of Sequences is not compatible with the standard SQL way of creating sequences.
So I had to add the following property to the JDBC Connection pool:
I recently read [1], and it had a very interesting notion.
The idea is to let the database generate JSON, and provide it straight into your client.
So I decided to find out if MariaDB had some support for this as well.
It does2.
So, it basically was nothing more then calling a NativeQuery on the EntityManager, and returning a concatted resultset with a '['prefix and a ']'postfix and a comma-delimiter and away we go.
The native query looked like the following:
It worked flawlessly!
Caveat: of course, this is only in the case where your middleware (as in this example) really doesn't need to do anything with the result.
I mean, you are going to have to do all checks in the database query.
I think this example shows its strength when you just really want to read a lot of data, and do not need to process it.
I have always used the stock install of MariaDB that came with CentOS 7, but I noticed recently that it is still only on 5.5 (at the time of writing, 5.5.60).
I never had any issues with it, until I tried to upgrade my Liferay CMS system. Apparently there are definite changes that are not incorporated into the 5.5.
I wished to moved to 10.3, which is the latest stable branch, and I can apparently do that (as indicated on the mariadb website1) by creating a MariaDB repository for DNF and then installing as usual.
Of course, first uninstall the 5.5 version.
It's as easy as pie.
The last part will probably require a payara application server reboot, though.
| Pool name | [obvious] |
| Resource Type | javax.sql.DataSource |
| Datasource classname | org.mariadb.jdbc.MariaDbDataSource |
Leave the rest as default.
| Name | Value |
|---|---|
| serverName | localhost |
| URL | jdbc:mariadb://localhost:3306/mmud |
| databaseName | mmud |
| user | username |
| password | itsasecret |
| Name | Value |
|---|---|
| JNDI Name | this is the name as the resource is defined in your application |
| Pool Name | the pool defined previously, it's a dropdown which is convenient. |
| Driver name | mariadb |
| Driver Module Name | com.mariadb |
| Module Slot | |
| Driver Class Name | org.mariadb.jdbc.Driver |
| Drive Datasource Class Name | |
| Driver XA Datasource Class Name |
| Name | [name] |
| JNDI Name | java:/jdbc/[name] |
| Driver Name | mariadb |
| Driver Module Name | [empty] |
| Driver Class Name | [empty] |
| Connection URL | jdbc:mariadb://localhost:3306/[databasename] |
| User name | root |
| Password | itsasecret |
| Security Domain | [empty] |
I am running MariaDB and I wish to execute sql scripts without all this hassle of entering my password. Of course this carries severe security risks with it, that we need to be aware of and, if possible, mitigate.
It is possible to execute sql scripts via the commandline1, but the problem here is that the password you use is visible in the process list. So this is a security risk.
Let's not do this.
I firstly checked out mysql_config_editor2, which enables you to put the password and other options into an encrypted configuration file. But it turns out that MariaDB does not come with that specific tool. The encryption used seems quite weak, and there's an article about the security issues at [3]. There is also the blogpost at [4] giving some details.
Well, there is always the plan to use the configuration file .my.cnf5, and you can store your mysql or mariadb password in there and everything would be hunky-dory.
The .my.cnf looks like this:
You are no doubt aware that the password is stored in cleartext.
The following security measures should be in place:
There is an example of a my.cnf containing every possible configuration option at /usr/share/mysql/my-large.cnf when you install MariaDB.
