Database Tables conversion process occurs on *every* upgrade?

[Jeeves]

Every upgrade, the "tables conversion" process has all the same tables selected, which says to me nothing has been done to them.
If it converts a table to UTF8 & InnoDB during .20, it shouldn't have to do the same for .21.

This occurs on multiple servers of mine, attached are an image from two of them at both the .20 and .21 upgrades.

During the .20 upgrade:

cacti-upgrade.png (22.42 KiB) Viewed 1236 times

Another during the .21 upgrade:

cacti-upgrade-everytime.png (42.25 KiB) Viewed 1236 times

[TheWitness]

You must have something that's changing the charset of your tables. We are using utf8mb4 for internationalization. Takes more data, but works just fine.

[Jeeves]

You must have something that's changing the charset of your tables. We are using utf8mb4 for internationalization. Takes more data, but works just fine.

I have this issue on multiple servers, the only thing those servers do is Cacti.

I'm all ears, but as far as I know the only thing that touches the cactidb IS Cacti. I know for a fact that nothing else has credentials to the db.

[TheWitness]

Make sure that the following is what is in your server.cnf file as well as verifying it's not in the client.cnf file if you have one.

Code: Select all

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

Once that's done, you should force the migration from the command line:

Code: Select all

php -q convert_tables.php --help
Cacti Database Conversion Utility, Version 1.2.21 (DB: 1.2.21), Copyright (C) 2004-2022 The Cacti Group

usage: convert_tables.php [--debug] [--innodb] [--utf8] [--table=N] [--size=N] [--rebuild] [--dynamic]

A utility to convert a Cacti Database from MyISAM to the InnoDB table format.
MEMORY tables are not converted to InnoDB in this process.

Required (one or more):
-i | --innodb  - Convert any MyISAM tables to InnoDB
-u | --utf8    - Convert any non-UTF8 tables to utf8mb4_unicode_ci

Optional:
-t | --table=S - The name of a single table to change
-n | --skip-innodb="table1 table2 ..." - Skip converting tables to InnoDB
-s | --size=N  - The largest table size in records to convert.  Default is 1,000,000 rows.
-r | --rebuild - Will compress/optimize existing InnoDB tables if found
     --dynamic - Convert a table to Dynamic row format if available
     --local   - Perform the action on the Remote Data Collector if run from there
-f | --force   - Proceed with conversion regardless of table size

-d | --debug   - Display verbose output during execution

You might have to increase the --size or other settings to make it work.

[TheWitness]

Once that is done, you can verify the changes from the Configuration > Settings > Technical Support > Database Tables page.

[Jeeves]

Once that is done, you can verify the changes from the Configuration > Settings > Technical Support > Database Tables page.

"Technical Support" is under "System Utilities", but yes. I found it.

I think I found the problem as well. Largely my own stupidity, but I'll explain.

I moved most critical cacti components to another path outside the main cacti path I then symlinked them. my RRA, Scripts, Config, etc. are all symlinked.
In this way I could nuke a path, and as long as I setup my symlinks were created, Cacti worked. I don't recall when I did this, but an update broke everything and I did this to save myself future headaches, it's been a long time.

Well, when updating cacti; I untar/gz in tmp, them delete config.php, then do: yes | cp -R * /../../cactipath/cacti

Apparently when doing so, the new files are not copied into the symlinked paths. This detail I was unaware of but discovered when convert_tables.php was missing.

So, it looks like maybe a check for the cacti setup could be useful? The php script it tried to run was missing for years.

Now I need to go re-evaluate my sanity and the cp command.

Thanks!

[TheWitness]

In my setups, or at least my home lab setup, I have the RRA directory symlinked to a CEPH volume. So, upgrading involves something like:

Code: Select all

cd /var/www/html
tar --exclude="*.gz" --exclude='rra' --exclude='log' --exclude='cache' -zcf backups/cacti_backup.$$.tgz
git clone -b 1.2.x https://github.com/cacti/cacti.git cacti-new
cp -rp cacti-net cacti
chown -R apache:apache cacti
rm -rf cacti-new

Double check by tar exclude syntax, but it's about right anyway. After that, I just hit the refresh button on the browser and follow the prompts.

[TheWitness]

Of course, going to the 1.2.x branch can be dangerous even though I try hard not to break it. Going to releases is better.

[Jeeves]

In my setups, or at least my home lab setup, I have the RRA directory symlinked to a CEPH volume. So, upgrading involves something like:

Code: Select all

cd /var/www/html
tar --exclude="*.gz" --exclude='rra' --exclude='log' --exclude='cache' -zcf backups/cacti_backup.$$.tgz
git clone -b 1.2.x https://github.com/cacti/cacti.git cacti-new
cp -rp cacti-net cacti
chown -R apache:apache cacti
rm -rf cacti-new

Double check by tar exclude syntax, but it's about right anyway. After that, I just hit the refresh button on the browser and follow the prompts.

That's not far off from how I set mine up, I appreciate the insight into your methods.
Personally; I only run releases. I need things working rather than being up to the minute updated
And as always, thanks for the support.

[netniV]

Honestly, I never mess around with cp. I just use git clone and then checkout to the tagged release you want.

[Jeeves]

Honestly, I never mess around with cp. I just use git clone and then checkout to the tagged release you want.

I don't use git on a day to day basis, so I tend to lean away from it's use.

[netniV]

I’ve heard that argument a lot from people but it’s as simple as

Code: Select all

git checkout release/1.2.21

[Jeeves]

I’ve heard that argument a lot from people but it’s as simple as

Code: Select all

git checkout release/1.2.21

I wasn't saying it was difficult, simply that if I'm more familiar with one tool than another, it's clear which will get favored.

[netniV]

Yaeh appreciate that, the other benefit of using the git method, you can see if someone messes with your files too