We're looking to re-run a migration and
# spicedb
a
We're looking to re-run a migration and to start the DB from scratch. We're using postgres. Deleting with bulk delete will take ~2+ days. Is it safe to truncate relation_tuple and relation_tuple_transaction?
there's a few ways to go about it though
one is to drop all of the databases and re-run the migrations
another is to set the
deleted_at
xid for all of the relation_tuples to a small number, which will cause the GC process to delete the rows
though depending on the number of rows that might also be pretty heavy
is the hope that this is an on-line process?
a
what do you mean by on-line process?
y
like will the database still be in use while you're doing this, or is downtime permissible?
a
oh, downtime is okay
y
then yeah i'd probably just drop all of the tables and re-run migrations
a
we toggled off traffic
k cool, ty
(and it's staging environment)
y
truncation has the potential to leave things in a weird state because of how the postgres MVCC implementation uses the internal transaction ID counter
a
yeah i see the issue link. nice error message 👍
What's the simplest way to rerun the migrations?
It looks like the operator keeps track of some state about migrations and so it gives us similar complaints about truncation when trying this in an ephemeral environment
j
you could just change to a new logical database
and drop the old one
if you're going to have downtime anyway
a
Okay interesting. So if we change the db name in the datastore URI in the config used by the operator for the same SpiceDBCluster, it'll know to start migration over?
y
it should, yeah. it will see that the migration tracking table is undefined, which is a signal that no migrations have been run.
a
Thanks folks we'll give that a look tomorrow
16 Views