+1 to make new master key name explicit parameter.
> 29 сент. 2020 г., в 16:35, Sergey Chugunov
> написал(а):
>
> Hello Nikolay,
>
>> AFAIKU There is third use-case for this mode.
>
> Sorry for the late reply.
>
> I took a look at the code and maintenance mode indeed looks a good match
>
Hello Nikolay,
> AFAIKU There is third use-case for this mode.
Sorry for the late reply.
I took a look at the code and maintenance mode indeed looks a good match
for changing master key situation.
I want to clarify only one thing. In current implementation we pass new
master key name via
Ivan,
If you come up with any ideas that may make this feature better, don't
hesitate to share them!
Thank you!
On Tue, Sep 22, 2020 at 11:27 AM Ivan Pavlukhin wrote:
> Sergey,
>
> Thank you for your answer. While I am not happy with the proposed
> approach but things never were easy.
Sergey,
Thank you for your answer. While I am not happy with the proposed
approach but things never were easy. Unfortunately I cannot suggest
100% better approaches so far. So, I should trust your vision.
2020-09-22 10:29 GMT+03:00, Sergey Chugunov :
> Ivan,
>
> Checkpointer in Maintenance Mode
Ivan,
Checkpointer in Maintenance Mode is started and allows normal operations as
it may be needed for defragmentation and possibly other cases.
Discovery is started with a special implementation of SPI that doesn't make
attempts to seek and/or connect to the rest of the cluster. From that
Sergey,
> From the code complexity perspective I'm trying to design the feature in
> such a way that all maintenance code is as encapsulated as possible and
> avoids massive interventions into main workflows of components.
Could please briefly tell what means do you use to achieve
Hello, Sergey.
> At the moment I'm aware about two use cases for this feature: corrupted PDS
> cleanup and defragmentation.
AFAIKU There is third use-case for this mode.
Change encryption master key in case node was down during cluster master key
change.
In this case, node can’t join to the
Ivan,
Sorry for some confusion, MM indeed is not a normal mode. What I was trying
to say is that when in MM node still starts and allows the user to perform
actions with it like sending commands via control utility/JMX APIs or
reading metrics.
This is the key point: although the node is not in
Sergey,
Thank you for your answer!
Might be I am looking at the subject from a different angle.
> I think of a node in MM as an almost normal one
I cannot think of such a mode as a normal one, because it apparently
does not perform usual cluster node functions. It is not a part of a
cluster,
Vladislav, Ivan,
Thank you for your questions and suggestions. Let me answer them.
Vladislav,
If I understood you correctly, you're talking about a node performing some
automatic actions to fix the problem and then join the cluster as usual.
However the original ticket [1] where we faced the
Sergey,
Actually, I missed the point that the discussed mode affects a single
node but not a whole cluster. Perhaps I mixed terms "mode" and
"state".
My next thoughts about maintenance routines are about special
utilities. As far as I remember MySQL provides a bunch of scripts for
various
Hi Sergey.
As I understand any switching from/to MM possible only through manual
restart a node.
But in your example that look like a technical actions, that only possible
in the case.
Do you plan to provide a possibility for client where he can make a
decision without a manual intervention?
For
Hello Ivan,
Thank you for raising the good question, I didn't think of Maintenance Mode
from that perspective.
In short, Maintenance Mode isn't related to Cluster States concept.
According to javadoc documentation of ClusterState enum [1] it is solely
about cache operations and to some extent
Hi Sergey,
Thank you for bringing attention to that important subject!
My note here is about one more cluster mode. As far as I know
currently we already have 3 modes (inactive, read-only, read-write)
and the subject is about one more. From the first glance it could be
hard for a user to
Hello Nikolay,
Created one, available by link [1]
Initially there was an intention to develop it under IEP-47 [2] and there
is even a separate section for Maintenance Mode there.
But it looks like this feature is useful in more cases and deserves its own
IEP.
[1]
Hello, Sergey!
Thanks for the proposal.
Let’s have IEP for this feature.
> 27 авг. 2020 г., в 10:25, Sergey Chugunov
> написал(а):
>
> Hello Igniters,
>
> I want to start a discussion about new supporting feature that could be
> very useful in many scenarios where persistent storage is
Hello Igniters,
I want to start a discussion about new supporting feature that could be
very useful in many scenarios where persistent storage is involved:
Maintenance Mode.
*Summary*
Maintenance Mode (MM for short) is a special state of Ignite node when node
doesn't serve user requests nor
17 matches
Mail list logo
