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
Once #928 is fixed, along with that fix will come the ability to unlink subscriptions when they are changed. It seems like a good idea initially to unlinksubscriptions on shutdown so that InfluxDB is not trying to send data to a stopped Kapacitor instance.
This will work well in more dynamic environments, since a clean shutdown Kapacitor instance will not leave any traces behind. In the case that you are just bouncing the Kapacitor service this is extra unneeded work but the overhead has been minimal in practice.
The text was updated successfully, but these errors were encountered:
This will cause data loss when the subscriptions are not present, it would be better to make it easier to clean up after subscriptions via a DROP ALL SUBSCRIPTIONS WITH NAME "aaaa" or similar query.
This seems to work: drop subscription "kapacitor-949368b5-34dd-44ac-aeec-65b4a7abec50" on "telegraf"."autogen" but it raises another question. If you do a show subscriptions, it looks like a subscription is on every database with retention autogen as well as on _internal as monitor. Which ones do you want to nuke?
Once #928 is fixed, along with that fix will come the ability to unlink subscriptions when they are changed. It seems like a good idea initially to unlinksubscriptions on shutdown so that InfluxDB is not trying to send data to a stopped Kapacitor instance.
This will work well in more dynamic environments, since a clean shutdown Kapacitor instance will not leave any traces behind. In the case that you are just bouncing the Kapacitor service this is extra unneeded work but the overhead has been minimal in practice.
The text was updated successfully, but these errors were encountered: