[erlang-questions] Mnesia startup woes
Mon Oct 11 17:41:00 CEST 2010
On Node A,
You may only complete this operation if mnesia is stopped (or the cluster is
Alternatively, you may want to explore mnesia:set_master_nodes() and
utilizing this on node B. it may reduce the number of steps to recover NodeB
as well as streamline the bring up
On Fri, Oct 8, 2010 at 5:10 AM, Evans, Matthew <> wrote:
> I have the following mnesia deployment. Two nodes (NodeA and NodeB) with
> disc_copies and disc_only_copies of tables (other nodes have ram copies of
> these tables too).
> NodeA starts first, followed by NodeB. NodeA is considered by the
> non-Erlang part of the system to be a master, and NodeB as the standby. When
> NodeB comes up (maybe much later) it calls the following code to get the
> schema from NodeA, join the party and copy the tables to itself (it will
> remove all files from the mnesia directory first):
> mnesia:change_config(extra_db_nodes, [NodeA]),
> mnesia:change_table_copy_type(schema, node(), disc_copies),
> Tabs = mnesia:system_info(tables) -- [schema],
> [mnesia:add_table_copy(Tab, node(), disc_copies) || Tab <- Tabs].
> We can not control when NodeB starts, if ever. So it's likely that NodeA
> will be the only disc_only node when the tables are created.
> What I notice is that if NodeA comes up first, the data is unusable until
> NodeB comes up. This makes the system unusable for that period of time.
> Certainly I can understand why we do that (we need consistent data), but
> what I was after is a way to reverse mnesia:change_config/2 to remove NodeB?
> I can do this on NodeA:
> [ mnesia:force_load_table(T) || T <- mnesia:system_info (tables) ].
> But was wondering if there is a better way? For example, to remove NodeB
> from NodeA's schema?
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions