Data_id reached maximum value

[OxyMethylene]

Hey

So today we got this error spamming on console..
[HawkEye] Exception: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Out of range value for column 'data_id' at row 1

I checked the maximum value from data_id and it was indeed at max value of an integer. So I've updated all id's to a lower value (current data_id - (min data_id - 1)) which worked fine for the database. They all changed, maximum value is now at 120 million, but when i started the server back up, it gave the same error again. Even if the maximum value is way under the maximum value of an integer.

I have a backup of the old database, so I can restore at any time, but how to reset the data_id the plugin is using?

Greetings Oxy.

Edit:
Database before: http://prntscr.com/d9xdxw
Database after edit: http://prntscr.com/d9xe2y

We are running a 1.7.10 FTb Infinity server, HawkEye version 1.0.7b

Edit 2:
I currently have it fixed. Forgot to reset the auto_increment value of the table.
But maybe best to keep in mind that some servers can cap an integer id :D

(We delete records older then 2 weeks every day and we still have 110mil records.)

[bob7l]

Damn I've never seen such a massive database lol. I'm pretty amazed your table has been able to sustain such a beating over the years.

This is also NOT an updated HawkEye reloaded build because the data_id column should be unsigned, yet you've made it very clear yours is signed. Our max is 4,294,967,295. So using the latest build and allowing your table to regenerate would be pretty beneficial.

The best "solution" i can think of is change the 32bit integer to a 64bit allowing a wider range. That'd mean you'd max at 18,446,744,073,709,551,615, which would be INCREDIBLY difficult to hit. Or you could just begin resetting your database every X months.

[OxyMethylene]

Well, the ID is reset now, so I'll leave it like this for now.

FTB Infinity is updating to 1.10, we're just waiting on a few mods/plugins to make the switch. So I think the Infinity 1.7.10 will either die out or calm down a lot. So I doubt we'll have the same issue again.

For the new server however, I guess i'll go to a 64bit integer, just to be safe.

Thanks for the reply :)

[RoboMWM]

Yea, I don't intend on purging old logs once I get cozy with a block logger, would prefer an option (unless it exists already) to use something like a 64-bit integer or similar

[bob7l]

4,294,967,295 is an absolutely MASSIVE amount of rows and I've never heard of anyone being able to increment the number that high. The only reason Oxy was able to do it is because he's using an outdated table scheme.

If more people run into this problem, I'll happily convert our fields to 64bit.