Internal Working
Rohit Manohar
I am trying to understand the internal working of Terrastore. I have
the following questions:
1. In active-passive setup, we don't tell the server about the passive
master. I am thinking that the server comes to know about the passive
master when it obtains a configuration file from the active master. Is
this correct?
2. I tired some fail over scenarios and could see that a revived
master gets the entire database from the active master (in compressed
form, maybe). However, if my revived master still has its data, can it
be configured to just get the delta from the active master?
3. If both the active and passive masters are killed, the server also
dies. Shouldn't it just wait there its master to be revived?
4. Can I obtain metadata about the documents in the store like data/
time of creation, last edited etc.
Regards,
Rohit Manohar
Sergio Bossa
> 1. In active-passive setup, we don't tell the server about the passive
> master.
We can actually tell the server about all available (active/passive)
masters, by providing a comma-separated list of hosts through the
--master startup option.
If we only specify the currently active master, the server takes the
whole list from it.
> 2. I tired some fail over scenarios and could see that a revived
> master gets the entire database from the active master (in compressed
> form, maybe). However, if my revived master still has its data, can it
> be configured to just get the delta from the active master?
Active/Passive synchronization is completely managed by the
(Terracotta) master: to enforce consistent state it will actually
force a full synchronization, but it is possible to tune buffers and
batches to speed it up depending on memory and network configurations.
> 3. If both the active and passive masters are killed, the server also
> dies. Shouldn't it just wait there its master to be revived?
The default behavior is to gracefully die in order to avoid freezing
the cluster in case of network partitions (that is, when the master
isn't actually died, but the server is partitioned away); in CAP
parlance, this is a CP behavior.
You can configure masters and servers to act differently and wait for
each other by setting the "server.reconnection.timeout" parameter
during master installation, and the "reconnectTimeout" during server
startup: the former, which is disabled by default, instructs the
master to wait for partitioned servers, the latter, which is enabled
and also controls server-to-passive reconnection, instructs the server
to wait for master reconnection.
> 4. Can I obtain metadata about the documents in the store like data/
> time of creation, last edited etc.
Nope: we don't have such a feature, currently.
Cheers,
Sergio B.
--
Sergio Bossa
http://www.linkedin.com/in/sergiob
Rohit Manohar
On Jun 9, 1:47 am, Sergio Bossa <sergio.bo...@gmail.com> wrote:
server-to-master reconnection when switching from active to passive in
case of failures of the former.
Consider that both my active and passive are dead. If I set
reconnectTimeout to very high, will that server handle requests (for
other masters) in an ensemble while its masters are dead OR continue
waiting for its masters to be revived OR both?
Sergio Bossa
> The documentation says reconnectTimeout is Timeout in milliseconds for
> server-to-master reconnection when switching from active to passive in
> case of failures of the former.
> Consider that both my active and passive are dead. If I set
> reconnectTimeout to very high, will that server handle requests (for
> other masters) in an ensemble while its masters are dead OR continue
> waiting for its masters to be revived OR both?
First, you also have to set the server.reconnection.timeout to wait in
case of complete master disconnection.
Then, the answer is yes, servers will still route your requests
through the ensemble, just waiting for the master reconnection if the
operation involves access to the dead master.