You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.)
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 channelirrd-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.The text was updated successfully, but these errors were encountered: