These days, I had a quite interesting email discussion. I am reproducing it here anonymized, as I think it is probably useful to get the “big picture” of where rsyslog is heading to.
I got the following request
Btw, I am trying to understand if it is possible to create this logic:
- specify 2 mysql servers (same schema)
- when rsyslog detects a writing failure on primary mysql server (let’s
say after the 1st retry)- start logging on the secondary server.
- rollback to primary server will be manual (sighup to rsyslogd or
something like this)
My reply was:
thanks for the suggestion. It actually is kind of on the todo list. Later this year, rsyslog will get a restartable queue interface. That is, when MySQL (or whatever else) goes down, messages are spooled to disk. When it comes back up, the spooled messages are written. All of this will happen in sequence.I am currently doing a big code restructuring, and one of the reasons for it is the restartable interface ;) It will be a very powerful and generic solution, but thus it will take some time. I anticipate some time around fall.
And after some further conversation, I wrote this:
Before a fully restartable interface, I’ll add a capability to work with backup actions. That is something like this
*.* >database-writer
&[onfail] >backup-database-writerThe rule with [onfail] in it would trigger only if the database-writer fails. I have a similar request for tcp forwarding and I think I can elegantly integrate it into the action processor, once the output module interface is fully implemented (which, unfortunately, it not yet is ;)).
This conversation quite good communicates the upcoming ideas and its use-cases. I personally think that around September I can begin to implement it. So the current order of events probably is (in that order)
- finish output module interface
- implement multiple actions per selector line (actually also improves performance for multiple actions with the same filter condition – this was the initial reason to design it)
- implement the failover mode for actions
- implement the queued interface
Along these actions, we need to implement automatic suspension/re-enabling of actions. I am not yet sure when this happens – it probably depends on when it is needed. Another good point of this functionality would be even more simplified output module code. This also serves as motivation. Another thing that will happen some time is the loadable plug-in interface – but that will probably be quite easy once the output module interface is finished.