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

When using PostgreSQL replication, preload store may not be updated #656

Closed
mxsasha opened this issue Jun 8, 2022 · 1 comment
Closed
Assignees
Labels
backport Should be backported to previous releases bug Something isn't working

Comments

@mxsasha
Copy link
Collaborator

mxsasha commented Jun 8, 2022

If an IRRD mirror runs on a replicated PostgreSQL database with database_readonly set, changes to the IRR data are invisible to IRRD. This means there is no signal to update the local preload store (for AS->prefix info), as that comes from changes being written through DatabaseHandler. This means IRRD will answer queries that use this preload store with stale data.

The only workaround for now is setting up a separate process that monitors database changes. If there is any change to a route(6) object, this process must send a Redis pubsub message to the channel irrd-preload-reload-channel. The content of the message is ignored. This will cause the preload store manager to queue an update of the local data. This integration is probably too deep into PostgreSQL setup to be included in IRRD itself at this time.

@mxsasha mxsasha added bug Something isn't working backport Should be backported to previous releases labels Jun 8, 2022
@mxsasha mxsasha self-assigned this Jun 8, 2022
mxsasha added a commit that referenced this issue Jun 23, 2022
@mxsasha
Copy link
Collaborator Author

mxsasha commented Oct 10, 2022

Some new thoughts: some opt-in PL/Python perhaps could be called from triggers with ENABLE REPLICA TRIGGER on the db. Then, a little bit of Python could kick the preload store, and the GPG importer if relevant. We may need to depend on the updated column to figure out which rows have been affected. If this works, it may allow PostgreSQL replication to become the main replication/HA method, with independent Redis instances per node.

Alternative: use the updated column in a single poller on replicas to check if any processes need updating. Definitely simpler, and probably acceptable delay. (We do need to index the column then.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport Should be backported to previous releases bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant