| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
OK, the previous attempt was a bit misguided. Rather than catch any
exception "inside" starting an app, log it and rethrow a token saying
no further logging is needed, let's just let the exception bubble out
and catch it once at the top level.
|
| |\ \
| |/ |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We used to have a weird situation where an error inside a boot step
would cause us to go through error logging twice. The exception would
get caught in run_step/3, then go through boot_error() etc, and
basic_boot_error/3 would exit again, leading to more stuff being
logged as an application start failure. So to fix that, let's
exit with a special atom which prevents further logging. Also
rename functions to be a bit more meaningful.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to clean up basic_boot_error/3, but these call sites make it
harder. Really, trying to produce nicely formatted errors here is a
waste of time, these errors can only be caused when adding boot steps.
Normal users should never see them. So don't complicate things by
handling them specially.
|
| | |/
| |
| |
| |
| | |
...and replace {boot_step, _, _} wrapping with an extra parameter which
might make it harder to make similar mistakes in future.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| | |
Conflicts:
.gitignore
|
| |\ \
| | |
| | | |
Add systemd notification support
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
When ERLANG_HOME is not set, exit with code 1
|
| |/ / / |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
No part of RabbitMQ does this type of checking, as pointed out by Simon.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
An admin could add nodes to the pause_if_all_down list before creating
the nodes.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that 'pause_if_all_down' accepts a list of preferred nodes, it is
possible that these nodes are spread across multiple partitions. For
example, suppose we have nodes A and B in datacenter #1 and nodes C and
D in datacenter #2, and we set {pause_if_all_down, [A, C]}, If the link
between both datacenters is lost, A/B and C/D forms two partitions.
RabbitMQ continues to run at both sites because all nodes see at least
one node from the preferred nodes list. When the link comes back, we
need to handle the recovery.
Therefore, a user can specify the strategy:
o {pause_if_all_down, [...], ignore} (default)
o {pause_if_all_down, [...], autoheal}
This third parameter is mandatory.
If the strategy is 'ignore', RabbitMQ is started again on paused nodes,
as soon as they see another node from the preferred nodes list. This is
the default behaviour.
If the strategy is 'autoheal', RabbitMQ is started again, like in
'ignore' mode, but when all nodes are up, autohealing kicks in as well.
Compared to plain 'autoheal' mode, the chance of loosing data is low
because paused nodes never drifted away from the cluster. When they
start again, they join the cluster and resume operations as any starting
node.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now, a partition is paused if all nodes from the pause_if_all_down list
are seen as down. If a fraction of the list is alive, the nodes in the
partition remain up.
Compared to the previous version, some of the listed nodes can be taken
down for maintenance without risking service interruption. However, this
raises the problem of listed nodes distributed in multiple partitions:
we need to handle recovery. This will be addressed in a followup commit.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The syntax is:
{cluster_partition_management, {keep_preferred, node@domain}}
The specified node name is used to determine which partition should run
or be suspended. Nodes which can still reach the specified node continue
to run. Nodes which can't are suspended.
Compared to pause_minority, this allows the admin to determine which
nodes to prioritize in case of partitions with an equal number of nodes.
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | |_|/
| |/| | |
|
| | | | | |
|
| |\ \ \ \ |
|
| | |\ \ \ \
| | |_|_|/
| |/| | | |
Fix a hilarious typo in the example config
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
orddict:append/2 uses ++ internally to build the list in the correct
order, which is O(length). So it's O(n^2) to call it n times. Instead
let's build the list backwards then reverse it - O(n).
|
| |\ \ \ |
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ / |
|
| | | | |
|
| |\ \ \
| |/ / |
|
| | |\ \ |
|
| | | | | |
|
| |\ \ \ \
| |/ / / |
|
| | | | | |
|
| |\ \ \ \ |
|
| | |\ \ \ \
| | |/ / /
| |/| | | |
|
| | |\ \ \ \
| | |_|/ /
| |/| | | |
|
| | |/ / /
| | | |
| | | |
| | | | |
socket could be closed; no point in blowing up if that is the case.
|
| |\ \ \ \
| | |/ /
| |/| | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
