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
allow change feed notifications for raft related data #4902
Comments
/cc @danielmewes Daniel, what do you think about this? |
A quick clarification ahead: RethinkDB uses one raft cluster per table. That means that for each table, a different server can be the Raft leader. How about exposing a Also pinging @VeXocide for any thoughts on this. |
@danielmewes ah right, I did fail to notice that this is per-table! Other than that, |
In the meantime, I've ended up with this reql to watch for leadership changes on a given table (
P.S. what penalty do I incur by attaching a change feed to such a slow query? |
strangely enough if I change the match line from:
to
I get a slightly slower query (but this is all based on Data Explorer, so I imagine the numbers are close enough). The query profile for the results are 44ms server time, and 54ms server time respectively |
I think reading the full log table might be what's slow here. It's not parsed in the most efficient way at the moment. You can make it a bit faster by stopping once you've found the first match: r.db('rethinkdb').table('logs')
.orderBy(r.desc({index: "id"}))
.filter(function(log) {
return log('message').match(config('id')).and(log('message').match('Raft leader'));
}).limit(1) I don't think we actually support changefeeds on such queries yet, since it involves fetching data from multiple tables. You can however get a changefeed on the r.db('rethinkdb').table('logs')
.filter(function(log) {
return log('message').match(tableId).and(log('message').match('Raft leader'));
})
.changes() |
@danielmewes thanks for the quick response. It looks like the plain filter on logs takes about 43ms server time (with a cached id), but adding the orderBy and limit reduced that by half. You had a typo with r.desc, so here's the filter for future readers:
|
@danielmewes so are you saying that even if |
additionally it seems that orderyBy.limit doesn't work on system tables, bummer! |
@mbroadst No that's not what I meant. I just meant that since your query uses both the table configuration as well as the The changefeed query I mentioned above on the r.db('rethinkdb').table('table_status').filter({id: tableId})('raft_leader').changes() You just need to retrieve the table ID before. Eventually you'll also be able to use the more efficient r.table(...).status()('raft_leader').changes() but this doesn't yet work because our changefeeds on single documents (rather than sequences) don't allow transformations (here: selecting the 'raft_leader' field) yet. We hope to add that functionality soon. |
@mbroadst Regarding Something like the mentioned
works fine for me. |
It's changefeed specific, I get this error:
|
Ah yes, that's true for changefeeds. You can just register a changefeed without the What I recommend doing is something like this:
RethinkDB 2.2 will have an |
Yep that's what I've got now! I am definitely looking forward to all these new features though 😄 |
@danielmewes is there possibly a way to forcibly change the raft leader for a table from e.g. reql? This would be incredibly useful for testing on our side |
@mbroadst Right now the only way is to take the server down or to interrupt the network connection (using |
We had a proposal for a debug interface to forcibly change the Raft leader, but it hasn't been implemented yet. I think we should eventually expose a system table API for all this (changing the Raft leader, subscribing to changes on it, etc.) |
@danielmewes and I spoke on IRC earlier and discussed the possibility of also adding a |
Merged into |
My immediate use case is to be informed of whether a given rethinkdb instance has become the leader, however this could potentially be useful for other cases. Temporarily I can set up a change feed on the logs table and filter for the term "Raft", however a more direct means would be ideal.
Though this was discussed briefly on the mailing list, no actual proposal was put forth. If this was something as simple as exposing a key like "raft_role" maybe on the
server_status
table (it looks like here: https://github.com/rethinkdb/rethinkdb/blob/next/src/clustering/administration/servers/server_status.cc#L40), then I could totally put together a PR for that, however I wanted to open up the issue here first to discuss potentially better alternatives (or interest in the first place!).The text was updated successfully, but these errors were encountered: