NameLayer shuts down the server on startup, "Migration Failed!"

[Murreey]

I'm in the process of upgrading server from 1.10 to 1.11.2, but when installing the newest build of NameLayer from this Jenkins server (2.10.0), I get a "Migration Failed!" error on start up, and the server shuts down again. It does not print a stack trace. We're currently running NameLayer 2.9.0.

Seems to be coming from this line, so best I figure is something is wrong with our MySQL set up.

Far as I can tell, the only tables that NameLayer is actually using are:

• Name_player, which just has a uuid and the player's name
• managed_plugin_data and managed_plugin_locks, which are both empty
• db_version, which has this in it:
• 

There may be others, but we have a lot of tables and these are the only ones I know belong to NameLayer. We don't use any of the other features like groups, just the name changing.

Let me know if I missed any info you need, and what changes need to be made to the DB if any.

Thanks!

[ProgrammerDan]

Ahhh, this is largely my fault as I've been dragging my feet on full-stack support for 1.11.x -- in theory the latest build supports 1.11.x but I don't know if it does in combination.

You should be ok to migrate from 2.9.0 to latest, but from the looks o the DB you posted there might be some issues.

I or another dev will look into it. If you are indeed only using the name-changing features then you are basically only using Name_player. managed_plugin_data should have the current version history in it; if it doesn't, then something is definitely going wrong in the update -- there was a major upgrade to the database infrastructure and while I made a best effort to cleanly support backwards compatible updates to the new infrastructure, my available systems for test were limited.

I'll try to get back to you soon with a mitigation. If possible please post your full startup trace with respect to NameLayer and CivModCore, especially the parts leading up the "Migration Failed!" message. Thanks!

[Murreey]

Awesome, thanks for the reply.

I tried manually running the query that is supposed to insert into managed_plugin_data but it failed as the timestamp column doesn't exist - is that supposed to be update_time?

This is all that's output by CivModCore and NameLayer, after this the server loads everything else, then shuts down:

[01:14:55] [Server thread/INFO]: [CivModCore] Enabling CivModCore v1.5.11
[01:14:55] [Server thread/INFO]: [NameLayer] Enabling NameLayer v2.10.0
[01:14:55] [Server thread/INFO]: [NameLayer] Preparing to generate ConnectionPool for NameLayer.
[01:14:55] [Server thread/INFO]: [NameLayer] Connecting to {database}@{url}:3,306 using {user}
[01:14:55] [Server thread/WARN]: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[01:14:55] [Server thread/WARN]: SLF4J: Defaulting to no-operation (NOP) logger implementation
[01:14:55] [Server thread/WARN]: SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[01:14:56] [Server thread/ERROR]: [NameLayer:] Stack Trace follows
 --------------------------------------
Migration failure!
 --------------------------------------

[ProgrammerDan]

I wonder if you caught some weird version of CivModCore before Migration was fully mature. There should definitely be a column in managed_plugin_data that captures when the update occurred:

 CREATE TABLE `managed_plugin_data` (
  `managed_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `plugin_name` varchar(120) NOT NULL,
  `management_began` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `current_migration_number` int(11) NOT NULL,
  `last_migration` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`managed_id`),
  UNIQUE KEY `uniq_managed_plugin` (`plugin_name`),
  KEY `idx_managed_plugin` (`plugin_name`) USING BTREE
)

That's from my live instance.

There should also be a companion table to deal with multiple servers sharing the same backing database to prevent race conditions on simultaneous deployment of updates, called managed_plugin_locks:

CREATE TABLE `managed_plugin_locks` (
  `plugin_name` varchar(120) NOT NULL,
  `lock_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`plugin_name`)
)

If either of these tables are missing or malformed, for certain all attempts at migration will fail.

[Murreey]

I'm using CivModCore 1.5.11 which is the latest from Jenkins. Both those tables are there and have the right structure, they're both empty though.

[ProgrammerDan]

Alright, I've got it.

Basically, the migration patchup I wrote for NameLayer appears to assume you were also running Citadel. I'll have to write a new version of the migration crossover to handle your case, but for now you can resolve this issue and get back to upgrading by running the following command:

ALTER TABLE db_version ADD COLUMN `timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;

This will add the expected timestamp column to the db_version table; it'll have dummy "now()" values for all rows, but that'll be enough to let the migration script run through after that. Basically satisfies https://github.com/DevotedMC/NameLayer/blob/master/namelayer-spigot/src/main/java/vg/civcraft/mc/namelayer/NameLayerPlugin.java#L148 allowing the rest of the migration to run.

Let me know if you have any other issues, and in the meantime I'll open a secondary ticket to address the more fundamental issue for users that are using Namelayer exclusively.

[Murreey]

That query fixed it, working great now. Thanks!