If I want to temporarily remove a server from my cluster to test various processes against, can I just set wsrep_on=off, do my testing and then re enable it? I can't recall if that will make the server stop responding entirely. Or do I need to shut it off and set it up in it's own cluster for a short time and then add it back to the live cluster? I just want to make sure if data is changed by some misfortune that those changes aren't replicated to the cluster.
> If I want to temporarily remove a server from my cluster to test
> various processes against, can I just set wsrep_on=off, do my testing
> and then re enable it? I can't recall if that will make the server
> stop responding entirely. Or do I need to shut it off and set it up
> in it's own cluster for a short time and then add it back to the live
> cluster? I just want to make sure if data is changed by some
> misfortune that those changes aren't replicated to the cluster.
> thanks
Yes, you can set wsrep_on=off globally and nothing will be replicated TO cluster. However the node will still receive and apply all events FROM cluster.
If you want the node to disconnect from cluster entirely, you need to
- either start a separate cluster by setting wsrep_cluster_address='gcomm://'
- or unload wsrep provider completely by setting wsrep_provider='none'
Regards,
Alex
-- Alexey Yurchenko,
Codership Oy, www.codership.com Skype: alexey.yurchenko, Phone: +358-400-516-011
I've tried both options and this is what happened:
1. Setting wsrep_provider='none':
Node get disconnected, and functional. But when i set again the
wsrep_provider with the path to libgalera_smm.so, the node get stalled in
initialized state.
Node get disconnected and boost a new cluster with it as only member. OK
I did some inserts on the "new" cluster and a delete on the "old" cluster
(with 2 node as members). The rows deleted also exists on the disconnected
node, but due that the node isn't in the old cluster, the rows keep
existing on it. OK
Then, i restored wsrep_cluster_address value to the original one. The node
joined the cluster with no problems but data never get synced: The rows i
deleted on the old cluster (and that was present on disconnected node)
still available on the rejoined node.
Still, the joined node can perform selects and new inserts with no problem.
But, when i did the same delete on the rejoined node, the entirely cluster
fail (because the classic row replication error HA_ERR_KEY_NOT_FOUND) and
the 2 nodes that was never being disconnected from original cluster ask for
SST. In other words: it was like a new cluster was boostraped, with the
aggravating that SST on one node failed, due Resource temporarily
unavailable. SST method: Xtrabackup.
So, i stayed with a single cluster, but with a single node.
My question is: When the node re join the cluster, this (the cluster)
shouldn't realize that the sequence number on the joiner node (and i
suppose, the UUID also different) in grastate.dat is different and request
an SST?
Thank you!
Regards
Daniel
2012/5/9 Alex Yurchenko <alexey.yurche...@codership.com>
>> If I want to temporarily remove a server from my cluster to test
>> various processes against, can I just set wsrep_on=off, do my testing
>> and then re enable it? I can't recall if that will make the server
>> stop responding entirely. Or do I need to shut it off and set it up
>> in it's own cluster for a short time and then add it back to the live
>> cluster? I just want to make sure if data is changed by some
>> misfortune that those changes aren't replicated to the cluster.
>> thanks
> Yes, you can set wsrep_on=off globally and nothing will be replicated TO
> cluster. However the node will still receive and apply all events FROM
> cluster.
> If you want the node to disconnect from cluster entirely, you need to
> - either start a separate cluster by setting wsrep_cluster_address='gcomm:/
> **/'
> - or unload wsrep provider completely by setting wsrep_provider='none'
> --
> You received this message because you are subscribed to the Google Groups
> "codership" group.
> To post to this group, send email to codership-team@googlegroups.**com<codership-team@googlegroups.com>
> .
> To unsubscribe from this group, send email to codership-team+unsubscribe@*
> *googlegroups.com <codership-team%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/** > group/codership-team?hl=en<http://groups.google.com/group/codership-team?hl=en>
> .
> I've tried both options and this is what happened:
> 1. Setting wsrep_provider='none':
> Node get disconnected, and functional. But when i set again the
> wsrep_provider with the path to libgalera_smm.so, the node get > stalled in
> initialized state.
> Node get disconnected and boost a new cluster with it as only member. > OK
> I did some inserts on the "new" cluster and a delete on the "old" > cluster
> (with 2 node as members). The rows deleted also exists on the > disconnected
> node, but due that the node isn't in the old cluster, the rows keep
> existing on it. OK
> Then, i restored wsrep_cluster_address value to the original one. The > node
> joined the cluster with no problems but data never get synced: The > rows i
> deleted on the old cluster (and that was present on disconnected > node)
> still available on the rejoined node.
> Still, the joined node can perform selects and new inserts with no > problem.
> But, when i did the same delete on the rejoined node, the entirely > cluster
> fail (because the classic row replication error HA_ERR_KEY_NOT_FOUND) > and
> the 2 nodes that was never being disconnected from original cluster > ask for
> SST. In other words: it was like a new cluster was boostraped, with > the
> aggravating that SST on one node failed, due Resource temporarily
> unavailable. SST method: Xtrabackup.
> So, i stayed with a single cluster, but with a single node.
> My question is: When the node re join the cluster, this (the cluster)
> shouldn't realize that the sequence number on the joiner node (and i
> suppose, the UUID also different) in grastate.dat is different and > request
> an SST?
The problem here is that at no point there UUID becomes different, sorry, I must have foreseen that. I guess setting wsrep_on=0 globally would have been the safest option. There is an idea to generate a new UUID every time wsrep_cluster_address is set to gcomm://, but that will break GTID continuity between cluster restarts. And that may be not what we want.
> 2012/5/9 Alex Yurchenko <alexey.yurche...@codership.com>
>> On 2012-05-09 19:48, Andy Thompson wrote:
>>> If I want to temporarily remove a server from my cluster to test
>>> various processes against, can I just set wsrep_on=off, do my >>> testing
>>> and then re enable it? I can't recall if that will make the server
>>> stop responding entirely. Or do I need to shut it off and set it >>> up
>>> in it's own cluster for a short time and then add it back to the >>> live
>>> cluster? I just want to make sure if data is changed by some
>>> misfortune that those changes aren't replicated to the cluster.
>>> thanks
>> Yes, you can set wsrep_on=off globally and nothing will be >> replicated TO
>> cluster. However the node will still receive and apply all events >> FROM
>> cluster.
>> If you want the node to disconnect from cluster entirely, you need >> to
>> - either start a separate cluster by setting >> wsrep_cluster_address='gcomm:/
>> **/'
>> - or unload wsrep provider completely by setting >> wsrep_provider='none'
>> --
>> You received this message because you are subscribed to the Google >> Groups
>> "codership" group.
>> To post to this group, send email to >> codership-team@googlegroups.**com<codership-team@googlegroups.com>
>> .
>> To unsubscribe from this group, send email to >> codership-team+unsubscribe@*
>> *googlegroups.com <codership-team%2Bunsubscribe@googlegroups.com>.
>> For more options, visit this group at http://groups.google.com/**
<alexey.yurche...@codership.com> wrote: > Hi Daniel,
> On 2012-05-10 18:47, Daniel Mauricio Guzmán Burgos wrote: > > Hi Alex
> > I've tried both options and this is what happened:
> > 1. Setting wsrep_provider='none':
> > Node get disconnected, and functional. But when i set again the > > wsrep_provider with the path to libgalera_smm.so, the node get
> > stalled in > > initialized state.
> Alright, you didn't tell the new Galera instance where to connect to.
> It is waiting for wsrep_cluster_address.
> > 2. Setting wsrep_cluster_address='gcomm://'
> > Node get disconnected and boost a new cluster with it as only
member.
> > OK
> > I did some inserts on the "new" cluster and a delete on the "old" > > cluster > > (with 2 node as members). The rows deleted also exists on the
> > disconnected > > node, but due that the node isn't in the old cluster, the rows keep
> > existing on it. OK
> > Then, i restored wsrep_cluster_address value to the original one.
The
> > node > > joined the cluster with no problems but data never get synced: The > > rows i > > deleted on the old cluster (and that was present on disconnected
> > node) > > still available on the rejoined node. > > Still, the joined node can perform selects and new inserts with no > > problem.
> > But, when i did the same delete on the rejoined node, the entirely > > cluster > > fail (because the classic row replication error
> > and > > the 2 nodes that was never being disconnected from original cluster
> > ask for > > SST. In other words: it was like a new cluster was boostraped, with
> > the > > aggravating that SST on one node failed, due Resource temporarily > > unavailable. SST method: Xtrabackup. > > So, i stayed with a single cluster, but with a single node.
> > Log of one of the nodes from original cluster:
> > My question is: When the node re join the cluster, this (the
cluster) > > shouldn't realize that the sequence number on the joiner node (and
i > > suppose, the UUID also different) in grastate.dat is different and > > request > > an SST?
> The problem here is that at no point there UUID becomes different,
> sorry, I must have foreseen that. I guess setting wsrep_on=0 globally
> would have been the safest option. There is an idea to generate a new
> UUID every time wsrep_cluster_address is set to gcomm://, but that
will
> break GTID continuity between cluster restarts. And that may be not
what
> we want.
> > Thank you!
> > Regards > > Daniel
> > 2012/5/9 Alex Yurchenko <alexey.yurche...@codership.com>
> >> On 2012-05-09 19:48, Andy Thompson wrote:
> >>> If I want to temporarily remove a server from my cluster to test
> >>> various processes against, can I just set wsrep_on=off, do my
> >>> testing > >>> and then re enable it? I can't recall if that will make the
server > >>> stop responding entirely. Or do I need to shut it off and set it
> >>> up > >>> in it's own cluster for a short time and then add it back to the > >>> live > >>> cluster? I just want to make sure if data is changed by some > >>> misfortune that those changes aren't replicated to the cluster.
> >>> thanks
> >> Yes, you can set wsrep_on=off globally and nothing will be
> >> replicated TO > >> cluster. However the node will still receive and apply all events > >> FROM > >> cluster.
> >> If you want the node to disconnect from cluster entirely, you need
> >> to > >> - either start a separate cluster by setting
> >> wsrep_cluster_address='gcomm:/ > >> **/' > >> - or unload wsrep provider completely by setting
> >> wsrep_provider='none'
> >> -- > >> You received this message because you are subscribed to the Google
> >> Groups > >> "codership" group. > >> To post to this group, send email to
> >> codership-team@googlegroups.**com<codership-team@googlegroups.com>
> >> . > >> To unsubscribe from this group, send email to
> >> codership-team+unsubscribe@* > >> *googlegroups.com <codership-team%2Bunsubscribe@googlegroups.com>.
> >> For more options, visit this group at http://groups.google.com/**
> --
> You received this message because you are subscribed to the Google
Groups
> "codership" group. > To post to this group, send email to codership-team@googlegroups.com.
> To unsubscribe from this group, send email to
> codership-team+unsubscribe@googlegroups.com. > For more options, visit this group at
> http://groups.google.com/group/codership-team?hl=en.
>>>> On 5/10/2012 at 02:09 PM, in message
> <d85517f33452e768a6ddd14a8db19...@codership.com>, Alex Yurchenko
> <alexey.yurche...@codership.com> wrote:
>> Hi Daniel,
>> On 2012-05-10 18:47, Daniel Mauricio Guzmán Burgos wrote:
>> > Hi Alex
>> > I've tried both options and this is what happened:
>> > 1. Setting wsrep_provider='none':
>> > Node get disconnected, and functional. But when i set again the
>> > wsrep_provider with the path to libgalera_smm.so, the node get
>> > stalled in
>> > initialized state.
>> Alright, you didn't tell the new Galera instance where to connect >> to.
>> It is waiting for wsrep_cluster_address.
>> > 2. Setting wsrep_cluster_address='gcomm://'
>> > Node get disconnected and boost a new cluster with it as only
> member.
>> > OK
>> > I did some inserts on the "new" cluster and a delete on the "old"
>> > cluster
>> > (with 2 node as members). The rows deleted also exists on the
>> > disconnected
>> > node, but due that the node isn't in the old cluster, the rows >> keep
>> > existing on it. OK
>> > Then, i restored wsrep_cluster_address value to the original one.
> The
>> > node
>> > joined the cluster with no problems but data never get synced: The
>> > rows i
>> > deleted on the old cluster (and that was present on disconnected
>> > node)
>> > still available on the rejoined node.
>> > Still, the joined node can perform selects and new inserts with no
>> > problem.
>> > But, when i did the same delete on the rejoined node, the entirely
>> > cluster
>> > fail (because the classic row replication error
> HA_ERR_KEY_NOT_FOUND)
>> > and
>> > the 2 nodes that was never being disconnected from original >> cluster
>> > ask for
>> > SST. In other words: it was like a new cluster was boostraped, >> with
>> > the
>> > aggravating that SST on one node failed, due Resource temporarily
>> > unavailable. SST method: Xtrabackup.
>> > So, i stayed with a single cluster, but with a single node.
>> > Log of one of the nodes from original cluster:
>> > My question is: When the node re join the cluster, this (the
> cluster)
>> > shouldn't realize that the sequence number on the joiner node (and
> i
>> > suppose, the UUID also different) in grastate.dat is different and
>> > request
>> > an SST?
>> The problem here is that at no point there UUID becomes different,
>> sorry, I must have foreseen that. I guess setting wsrep_on=0 >> globally
>> would have been the safest option. There is an idea to generate a >> new
>> UUID every time wsrep_cluster_address is set to gcomm://, but that
> will
>> break GTID continuity between cluster restarts. And that may be not
> what
>> we want.
>> > Thank you!
>> > Regards
>> > Daniel
>> > 2012/5/9 Alex Yurchenko <alexey.yurche...@codership.com>
>> >> On 2012-05-09 19:48, Andy Thompson wrote:
>> >>> If I want to temporarily remove a server from my cluster to test
>> >>> various processes against, can I just set wsrep_on=off, do my
>> >>> testing
>> >>> and then re enable it? I can't recall if that will make the
> server
>> >>> stop responding entirely. Or do I need to shut it off and set >> it
>> >>> up
>> >>> in it's own cluster for a short time and then add it back to the
>> >>> live
>> >>> cluster? I just want to make sure if data is changed by some
>> >>> misfortune that those changes aren't replicated to the cluster.
>> >>> thanks
>> >> Yes, you can set wsrep_on=off globally and nothing will be
>> >> replicated TO
>> >> cluster. However the node will still receive and apply all events
>> >> FROM
>> >> cluster.
>> >> If you want the node to disconnect from cluster entirely, you >> need
>> >> to
>> >> - either start a separate cluster by setting
>> >> wsrep_cluster_address='gcomm:/
>> >> **/'
>> >> - or unload wsrep provider completely by setting
>> >> wsrep_provider='none'
>> --
>> You received this message because you are subscribed to the Google
> Groups
>> "codership" group.
>> To post to this group, send email to >> codership-team@googlegroups.com.
