When upgrading from older MySQL databases, format is not changed from compact to dynamic

[krishnagummadapu]

Hi All,
I tried to upgrade the Cacti database to version 1.2.5 and got the well known error "ALTER TABLE poller_output_realtime DROP PRIMARY KEY, ADD PRIMARY KEY (local_data_id, rrd_name, time, poller_id)

little google helped me to manually run that command.
But now my issue is the Cacti page is still sitting at the Error. I tried to restart the database and restarted the system itself. But no use.
How do I proceed/restart the upgrade process from here.

[clayton-colovore]

I have exactly the same issue. How do I trick the installer wizard into proceeding past this page?

[bmfmancini]

have you enabled large_prefix =1 on my mysql config ?

…

On Tue, Oct 29, 2019 at 3:45 PM clayton-colovore ***@***.***> wrote: I have exactly the same issue. How do I trick the installer wizard into proceeding past this page? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3060?email_source=notifications&email_token=ADGEXTHOVXN4GVTTF34REN3QRCHFPA5CNFSM4JGCB4KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECR22HI#issuecomment-547597597>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGEXTF2H7S3ZAG7XD4MWDDQRCHFPANCNFSM4JGCB4KA> .

-- Thank you Sean Mancini Owner/Principal Engineer www.seanmancini.com “Companies spend millions of dollars on firewalls, encryption, and secure access devices, and it’s money wasted because none of these measures address the weakest link in the security chain.” *– Kevin Mitnick*

[clayton-colovore]

have you enabled large_prefix =1 on my mysql config

not initially, but yes while setting the correct character set and collation options. even after I was able to run the ALTER TABLE line above successfully, the installer would not proceed further. watched with both SHOW PROCESSLIST and tcpdump and saw no evidence that the installer ever tried to rerun the ALTER TABLE statement

I ended up restoring yesterday's db backup and rerunning the upgrade

[krishnagummadapu]

That did the trick.
Enabled the Large_prefix = 1 and did work.
Thank you.

[tomck]

I had to learn that it was innodb_large_prefix=1 to get it to even let me restart mysql, but this did not resolve the issue for me. The other threads about this issue don't seem to be as simple. I will admit I have the wrong type of innodb (Anaconda instead of Barracuda) but I wasn't the one who set this up and I worry about the difficulties arising from changing database formats. Besides, now that I've gotten past that part of the process the only option the installer gives, even when trying to go to the homepage, is immediately jumping to the database upgrade page.

However after running the suggested cli upgrade_database.php here, #2824 (comment), it seems to work even though the installer thinks it failed. 🤷‍♂

[TheWitness]

What happens when you try to run the one command manually?

[ddb4github]

Before MySQL 5.7 and MariaDB 10.2.2 introduce option innodb_default_row_format , default row format is not "Dynamic".
Then ALTER SQL will failure

[netniV]

I am not sure i follow

[cigamit]

I think we should mandate innodb_default_row_format = Dynamic cause in MySQL 8.x, none of the recommendations remain, that includes Braracuda, or large_prefix. What a mess.

[ddb4github]

Current cacti.requiement.mysql=5.1+

MariaDB [cacti]> show variables like 'version';
+---------------+----------------+
| Variable_name | Value          |
+---------------+----------------+
| version       | 5.5.64-MariaDB |
+---------------+----------------+
MariaDB [cacti]> set global innodb_default_row_format=Dynamic;
ERROR 1193 (HY000): Unknown system variable 'innodb_default_row_format'

[ddb4github]

BTW, SQL below success both on 5.5 and 5.7, what ever current row format:

ALTER TABLE poller_output_realtime ROW_FORMAT=Dynamic, DROP PRIMARY KEY, ADD PRIMARY KEY (local_data_id, rrd_name, time, poller_id);

[cigamit]

I think adding ROW_FORMAT=Dynamic to that alter is a good idea actually. What do you think @netniV?

[cigamit]

There are a truck load of ALTERS though in the install directory though. It's almost as if we should somehow do a dynamic sweep before doing all the upgrade steps. Maybe we make that the first step in the upgrade. Might take a while if a user has a lot of big plugin tables, which makes the upgrade service impacting more so than the current procedure.

So, we should handle MyISAM > InnoDB, Latin > UTF8mb4 first and not last and that should include the DYNAMIC flag. What do you think?

[netniV]

Moving the conversion process to the front of the queue is not a bad plan. But as stated, for really large tables and/or slower systems, that could take some time rendering the system unusable until each table is completed in turn.

In the past, it was very easy to just let the DBA decide the best course to take with regards to formats and options but more and more, specific functionality (such as long keys) a requiring us to lock all that down.