aboutsummaryrefslogtreecommitdiffstats
path: root/lib/mnesia/src/mnesia_schema.erl
AgeCommit message (Collapse)Author
2011-09-15[mnesia] Fix schema conversion to previous versionsDan Gudmundsson
2011-09-15[mnesia] Whitespace fixesDan Gudmundsson
2011-09-15[mnesia] Mnesia schema merge tested with 2 nodes, r13b04 -> r14b (dev)Ulf Wiger
The do_merge_schema function now converts cstructs from a remote node when it detects that they are different. In order to be compatible the other way around, mnesia_controller:get_cstructs() detects a remote caller, and converts the cstructs before sending them.
2011-05-17Merge branch 'uw/mnesia-majority' into devHenrik Nord
* uw/mnesia-majority: dialyzer warning on mnesia_tm Add documentation text about majority checking add mnesia_majority_test suite where_to_wlock optimization + change_table_majority/2 bug in mnesia_tm:needs_majority/2 optimize sticky_lock maj. check check majority for sticky locks Write locks now check majority when needed. Add {majority, boolean()} per-table option. OTP-9304
2011-05-16where_to_wlock optimization + change_table_majority/2Ulf Wiger
2011-05-16Write locks now check majority when needed.Ulf Wiger
Since the table loader also sets (table) write locks, a special lock type, 'load', was needed. Unfortunately, this affects mnesia activity callbacks that redefine the lock operation.
2011-05-16Add {majority, boolean()} per-table option.Ulf Wiger
With {majority, true} set for a table, write transactions will abort if they cannot commit to a majority of the nodes that have a copy of the table. Currently, the implementation hooks into the prepare_commit, and forces an asymmetric transaction if the commit set affects any table with the majority flag set. In the commit itself, the transaction will abort if it cannot satisfy the majority requirement for all tables involved in the thransaction. A future optimization might be to abort already when a write lock is attempted on such a table (/-object) and the lock cannot be set on enough nodes. This functionality introduces the possibility to automatically "fence off" a table in the presence of failures. This is a first implementation. Only basic tests have been performed.
2011-05-12Use recover_nodes when deciding alive nodesDan Gudmundsson
Fixes timing issue in test cases
2011-03-09Abort/restart if network has changed, can be a partioned networkDan Gudmundsson
2010-06-04Merge branch 'uw/mnesia-schema-merge' into devErlang/OTP
* uw/mnesia-schema-merge: remove debug printout and accidental variable name reuse Allow a user_defined function to wrap mnesia_schema:merge_schema()
2010-06-02remove debug printout and accidental variable name reuseUlf Wiger
2010-06-02Allow a user_defined function to wrap mnesia_schema:merge_schema()Ulf Wiger
Mnesia currently notifies the user if it detects a partitioned network, but the options for resolving the situation are limited. In practice, the only safe options are: - set master_nodes and restart one of the affected 'islands' - restart the entire system from backup This patch introduces a way to resolve the situation without restarting any nodes. The key to doing this safely is to lock affected tables and run the merge function inside the same transaction that merges the schema. Otherwise, one transaction will merge the schema, after which writes to the database will be replicated across the (potentially) inconsistent copies; the transaction triggered by the asynchronous inconsistency event will have to race to be the first to access the tables. The normal call to merge the schema is done from mnesia_controller. Previously, this was mnesia_schema:merge_schema(). The new function is merge_schema(UserFun), with the following behaviour: merge_schema(UserFun) -> schema_transaction( fun() -> UserFun(fun(Arg) -> do_merge_schema(Arg) end) end). Where do_merge_schema(LockTabs) will execute the schema merge as before, but also lock all tables in the list LockTabs which have copies on the affected nodes (that is, everywhere the schema table is locked). The effect of this is to allow a wrapper function that calls the merge and, if successful, continues to resolve the inconsistency on the tables, knowing that they have now been locked on all affected nodes. The function that is actually called by the deconflict function is mnesia_controller:connect_nodes(Nodes, UserFun), as in: Tables = tables_to_deconflict(Node), mnesia_controller:connect_nodes( [Node], fun(MergeF) -> case MergeF(Tables) of {merged,_,_} -> deconflict(Tables, Node); Other -> Other end). In the case where the merge fails, it is probably wise to restart from a backup... I have not run the mnesia test suite, as it is not available. I have not updated documentation, as these functions are not documented in the first place.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP