[Gluster-users] How to manually/force remove a bad geo-rep agreement?
Vijaykumar Koppad
vkoppad at redhat.com
Wed Apr 30 09:03:53 UTC 2014
On 04/29/2014 07:15 PM, Steve Dainard wrote:
> Do you have a link to the doc's that mention a specific sequence
> particular to geo-replication enabled volumes? I don't see anything on
> the gluster doc page here:
> http://www.gluster.org/community/documentation/index.php/Main_Page.
Check out,
http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.5
Regards,
Vijaykumar
>
> Thanks,
> Steve
>
> On Tue, Apr 29, 2014 at 2:29 AM, Vijaykumar Koppad <vkoppad at redhat.com
> <mailto:vkoppad at redhat.com>> wrote:
>
>
> On 04/28/2014 08:31 PM, Steve Dainard wrote:
>> 3.4.2 doesn't have the force option.
> Oh, I got confused with releases.
>
>>
>> I went through an upgrade to 3.5 which ended in my replica pairs
>> not being able to sync and all commands coming back with no
>> output. Individually each node would mount its volumes and report
>> status ok until the other node was contacted. Logs had no useful
>> information. I did an upgrade on another replica pair without
>> issue before attempting my primary storage pair and had no issues.
> With geo-rep when you are upgrading, there are some special steps,
> you need to follow.
> If you have followed, it looks like there is some problem with the
> steps.
>
> -Vijaykumar
>
>>
>> I ended up restoring from backups and rebuilding my primary
>> storage pair.
>>
>> Not looking forward to the next upgrade.
>>
>> *Steve Dainard *
>> IT Infrastructure Manager
>> Miovision <http://miovision.com/> | /Rethink Traffic/
>>
>> *Blog <http://miovision.com/blog> | **LinkedIn
>> <https://www.linkedin.com/company/miovision-technologies> |
>> Twitter <https://twitter.com/miovision> | Facebook
>> <https://www.facebook.com/miovision>*
>> ------------------------------------------------------------------------
>> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101,
>> Kitchener, ON, Canada | N2C 1L3
>> This e-mail may contain information that is privileged or
>> confidential. If you are not the intended recipient, please
>> delete the e-mail and any attachments and notify us immediately.
>>
>>
>> On Mon, Apr 28, 2014 at 3:09 AM, Vijaykumar Koppad
>> <vkoppad at redhat.com <mailto:vkoppad at redhat.com>> wrote:
>>
>>
>> On 04/24/2014 07:40 PM, Steve Dainard wrote:
>>> # gluster volume geo-replication rep1
>>> gluster://10.0.11.4:/rep1 stop
>>> geo-replication command failed'
>> Try out
>>
>> # gluster volume geo-replication rep1
>> gluster://10.0.11.4:/rep1 stop force
>> # gluster volume geo-replication rep1
>> gluster://10.0.11.4:/rep1 delete
>>
>> -Vijaykumar
>>>
>>> cli.log:
>>> 2014-04-24 14:08:03.916112] W
>>> [rpc-transport.c:175:rpc_transport_load] 0-rpc-transport:
>>> missing 'option transport-type'. defaulting to "socket"
>>> [2014-04-24 14:08:03.918050] I [socket.c:3480:socket_init]
>>> 0-glusterfs: SSL support is NOT enabled
>>> [2014-04-24 14:08:03.918068] I [socket.c:3495:socket_init]
>>> 0-glusterfs: using system polling thread
>>> [2014-04-24 14:08:04.146710] I [input.c:36:cli_batch] 0-:
>>> Exiting with: -1
>>>
>>>
>>>
>>> *Steve Dainard *
>>> IT Infrastructure Manager
>>> Miovision <http://miovision.com/> | /Rethink Traffic/
>>>
>>> *Blog <http://miovision.com/blog> | **LinkedIn
>>> <https://www.linkedin.com/company/miovision-technologies> |
>>> Twitter <https://twitter.com/miovision> | Facebook
>>> <https://www.facebook.com/miovision>*
>>> ------------------------------------------------------------------------
>>> Miovision Technologies Inc. | 148 Manitou Drive, Suite 101,
>>> Kitchener, ON, Canada | N2C 1L3
>>> This e-mail may contain information that is privileged or
>>> confidential. If you are not the intended recipient, please
>>> delete the e-mail and any attachments and notify us immediately.
>>>
>>>
>>> On Thu, Apr 24, 2014 at 9:47 AM, Steve Dainard
>>> <sdainard at miovision.com <mailto:sdainard at miovision.com>> wrote:
>>>
>>> Version: glusterfs-server-3.4.2-1.el6.x86_64
>>>
>>> I have an issue where I'm not getting the correct status
>>> for geo-replication, this is shown below. Also I've had
>>> issues where I've not been able to stop geo-replication
>>> without using a firewall rule on the slave. I would get
>>> back a cryptic error and nothing useful in the logs.
>>>
>>> # gluster volume geo-replication status
>>> NODE MASTER SLAVE STATUS
>>> ---------------------------------------------------------------------------------------------------
>>> ovirt001.miovision.corp rep1 gluster://10.0.11.4:/rep1
>>> faulty
>>> ovirt001.miovision.corp miofiles
>>> gluster://10.0.11.4:/miofiles faulty
>>>
>>> # gluster volume geo-replication rep1
>>> gluster://10.0.11.4:/rep1 start
>>> geo-replication session between rep1 &
>>> gluster://10.0.11.4:/rep1 already started
>>> geo-replication command failed
>>>
>>> [root at ovirt001 ~]# gluster volume geo-replication status
>>> NODE MASTER SLAVE STATUS
>>> ---------------------------------------------------------------------------------------------------
>>> ovirt001.miovision.corp rep1 gluster://10.0.11.4:/rep1
>>> faulty
>>> ovirt001.miovision.corp miofiles
>>> gluster://10.0.11.4:/miofiles faulty
>>>
>>>
>>> How can I manually remove a geo-rep agreement?
>>>
>>> Thanks,
>>>
>>>
>>> *Steve
>>> *
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140430/9ead8763/attachment.html>
More information about the Gluster-users
mailing list