[erlang-questions] Mnesia startup woes

On Node A,
mnesia:del_table_copy(schema, NodeB).
You may only complete this operation if mnesia is stopped (or the cluster is
down)
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
--b
On Fri, Oct 8, 2010 at 5:10 AM, Evans, Matthew <> wrote:
> Hi,
>> 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?
>> Thanks
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html> To unsubscribe; mailto:>>