| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
* dgud/mnesia/add_index_crash/OTP-9285:
Fix mnesia crash when adding index on non loaded tables.
|
|
Fixes timing issue in test cases
|
|
This could happen on ram_copies tables.
|
|
|
|
|
|
|
|
|
|
"When I run mnesia:first on an empty fragmented table, it tries to
access the fragment with the number one beyond the maximum. In the
sample code below, I create a table with two fragments, 'foo' and
'foo_frag2', but mnesia tries to access 'foo_frag3':"
|
|
|
|
|
|
With help from Kostis
|
|
|
|
That caused a 'log_header' entry to added to the disc_copies tables.
|
|
Resolve name clash with auto-imported BIF error/2.
|
|
|
|
|
|
* uw/mnesia-overload:
Enable continuous monitoring of mnesia overload status
|
|
* uw/mnesia-schema-merge:
remove debug printout and accidental variable name reuse
Allow a user_defined function to wrap mnesia_schema:merge_schema()
|
|
|
|
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.
|
|
Mnesia currently issues an event whenever it detects an overload
condition. It recognizes two different types of overload:
- whenever the message queue of mnesia_tm process grows large
- when a log dump interval triggers before the previous dump is done
These events could be used to trigger a load regulation mechanism
to reduce the load until the condition seizes. The missing piece
is that there is no facility to ask mnesia whether the overload
condition still exists.
This patch implements a couple of functions in mnesia_lib that
can be used to sample the overload status. It has been tested
in a load regulator component being developed by Erlang Solutions.
No mnesia test suites have been run, since they are not available.
No documentation has been updated. The functions in mnesia_lib
are at any rate undocumented (as are all other functions in that
module). A decision would have to be made about whether to provide
a documented API on top of these functions.
The internal state record of mnesia_recover has been modified.
For this reason, a code change hook has been provided.
|
|
* bd/mnesia-activity-subscription:
Add mnesia activity subscription message
|
|
A process that calls mnesia:subscribe(activity) will receive the message:
{mnesia_activity_event, ActivityID, complete}
when any activity that caused a change to a database has finished
committing its changes. This allows a subscriber to collect messages
already available through the mnesia:subscribe({table, ...}) system
to group them as completed transactions.
|
|
|
|
invoking mnesia:sync_transaction/[1,2]. Thanks Igor Ribeiro
Sucupira.
|
|
* is/mnesia-send-compressed:
Add option to compress data when copying tables between Mnesia nodes
OTP-8406 Igor Ribeiro Sucupira added the option to compress data when
copying tables between Mnesia nodes.
|
|
Optionally using data compression for copying Mnesia tables allows
the system to be tuned to eliminate network bottlenecks from
deployments where enough CPU is available to use zlib.
With this patch, running erl -mnesia send_compressed <level>
will enable compression for sending tables between nodes. The
compression level can be any integer in [0, 9], with 0 (the
default) meaning no compression (exactly the previous behaviour)
and 9 being the highest compression level.
To set any non-zero compression level at the sender, both nodes
must have the updated Mnesia modules (the receiver will work
according to the sender's configuration).
|
|
|
