[Opendnssec-user] upgrade debian Jessie to Stretch: database trouble

[Berry A.W. van Halderen]

On 11/02/2017 10:42 AM, Dennis Baaten wrote:
> I upgraded my server from Debian Jessie (8) to Debian Stretch (9; the
> newest Stable release). With this upgrade OpenDNSSEC is upgraded from
> 1.4.6 to 2.0.3, while Mysql 5.5.58 is upgraded to MariaDB 10.1.26. My
> current OpenDNSSEC implementation uses a MySQL backend and follows the
> principle of ‘input and output files’.

Version 2.0.3 is an outdated version.  We're on 2.1.3 now, where
branch 2.0 is replaced by the 2.1 branch.  Delays in pushing updates
through the Linux distros release chain is not really under our control.

> During the upgrade I was made aware of the fact that the OpenDNSSEC
> upgrade to 2.0.3 requires two steps. Quote:
> 
> In an attempt to migrate the database, I first ran the
> migrate_1_4_8.mysql. This threw the error that KEYDATA_VIEW already
> existed. As this table was empty, I removed it, and ran the remaining
> part of the SQL from migrate_1_4_8.mysql again. This resulted in a view
> with the name KEYDATA_VIEW. No further errors.

Wasn't it upgraded already?

> The next step (migrating to 2.0 db) involves running of convert_mysql in
> Bash. Initially this results in “error 1071 specified key was too long
> max key length is 767 bytes”. I tried to resolve this by setting the
> InnoDB variable innodb_file_format to ‘Barracuda’ and enabling
> innodb_large_prefix. This resulted in a new but similar error: “error
> 1709 index column size too large. The maximum column size is 767
> bytes.”. And I’ve not been able to resolve this, which basically means
> that I’m stuck in the migration process towards OpenDNSSEC 2.0 and
> cannot start the relevant services on my server.

Contacted off-list for further database dumps.  I would expected any
need to really change the file format or prefixes.  That seems real
odd.  The biggest index we have is (rightfully) on a keylocator column
of 255 bytes.  Almost all others are on integers.  I suspect some
polluting has occurred in the database and contains some weird
data in certain columns.

\Berry