feat(db): Switch MySQL to Bitnami and Upgrade PostgreSQL

[sylus]

Even though we state to use Managed Databases in Production for those that do use the containerized versions we need to switch the MySQL containerized to the Bitnami charts due to stable charts deprecation. In addition I updated the PostgreSQL Bitnami chart as both the MySQL and PostgreSQL charts align roughly in configuration values in recent releases

Note: In the changelog I mention this is a breaking change with respect to the MySQL switch and that you must export and restore the database.

@zachomedia could I have your review on this? ^_^

[bernardmaltais]

So, besides the need to restore the DB from a previous backup when switching to this new container for MySQL, there should be no other noticeable issues?

[sylus]

@bernardmaltais there shouldn't be no but I should probably make a note to update the syntax for the MySQL | PostgreSQL settings such as setting the password.

That being said @zachomedia if want to give this a test yourself that would be great :D

Probably in future we should add a k3s CI testing suite of this helm chart, which we do for a few other repos, though this one would be a bit more involved.

[bernardmaltais]

@sylus Indeed, there will be a bit of moving values around to the new ones.

[bernardmaltais]

@sylus I did a quick restore test and it worked. On the other hand the backup cronjob is failing with the following error:

> mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

There might be other side effects also... need more testing

Update 1:

I am investigating how we are setting the passwords via encrypted files. I suspect I need to add the auth: section in there... yep... hope this will fix the backup issue...

Update 2:

No difference. The backup job will need some tweaking to start working again.

Update 3:

I tried adding this option to the drusb sqldump command with no luck as recommended here https://anothercoffee.net/how-to-fix-the-mysqldump-access-denied-process-privilege-error/:

--extra --no-tablespaces

Update 4:

OK, I was close but I finally found the solution. The following option needed to be used:

--extra-dump=--no-tablespaces

So the end result for the cron backup command need to be:

drush -y sql-dump {{ .Values.drupal.backup.sqlDumpArgs }} --extra-dump=--no-tablespaces | gzip > /backup/$BACKUPNAME/db.sql.gz

[bernardmaltais]

@sylus I also noted another difference. The mysql PVC does not get destroyed as part of the uninstallation of the chart. This will leave the mysql PVC permanently mounted and will cause issue if you try to re-deploy the chart without 1st deleting the PVC manually...