Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database primary key reached maximum value of sequence #5501

Open
zkonge opened this issue Sep 18, 2024 · 2 comments
Open

Database primary key reached maximum value of sequence #5501

zkonge opened this issue Sep 18, 2024 · 2 comments
Labels
help wanted Issues with this label are ready to start work but are in need of someone to do it priority/backlog Issue is approved and in the backlog

Comments

@zkonge
Copy link

zkonge commented Sep 18, 2024

  • Version: 1.10.4 (and order)
  • Platform: Linux super-dev 6.1.0-25-amd64 CLI authentication #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux
  • Subsystem: server

What happened

Our psql raised the "error reached maximum value of sequence" by node_resolver_map_entries_id_seq. And server down.

We have a large amount of agents. and some of the agents we deploy are constantly restarting,

Why

ID uint `gorm:"primary_key"`

It is seems that the ID field in node_resolver_map_entries is not enough in such scenarios.

SPIRE, which uses gorm v1, will mapping the uint to int type in DB and uint64 to bigint (By the way, gorm v2 will mapping both uint and uint64 to bigint).

Each agent restarting (or attestation) will increase the node_resolver_map_entries_id_seq value.

What to do

Modify the type? Use uint64 in Model primary key.

I'm worried about the DDL modification in the migration, for a large table, the type modification will lock the whole table and the server will down.

@azdagron azdagron added help wanted Issues with this label are ready to start work but are in need of someone to do it priority/backlog Issue is approved and in the backlog labels Sep 19, 2024
@azdagron
Copy link
Member

I don't think we have a choice other than migrating. We'll have to be careful with our use of AutoMigrate though. We may need to investigate if gorm v1 has a way to tag the ID to use a bigint instead of int (maybe declaring our own model type that defines ID as uint64 or something).

@zkonge
Copy link
Author

zkonge commented Sep 19, 2024

spire has already use its own Model type.

The auto migrate in gorm v1 doesn't modify the field type, so I think maybe changing the field type uint -> uint64 is enough.

In such case, all new created database will use the bigint as primary key and old will still uses the int.

And current uint is 64bit (in 64bit platform), so no overflow happens even downgrading (mostly?). I have no idea how many users use 32 bit platform to host spire-server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Issues with this label are ready to start work but are in need of someone to do it priority/backlog Issue is approved and in the backlog
Projects
None yet
Development

No branches or pull requests

2 participants