Hi All,
I still have the same problem, the data seems to be synchronized but
extremely slow. When I delete a file, it takes more than 24h to
replicate it. Do you know if it is possible to monitor the change-log queue?
-- Kindest regards,
Milos Cuculovic
IT Manager
--
MDPI AG
Postfach, CH-4005 Basel, Switzerland
Office: Klybeckstrasse 64, CH-4057 Basel, Switzerland
Tel. +41 61 683 77 35
Fax +41 61 302 89 18
Email: cuculovic@xxxxxxxx
Skype: milos.cuculovic.mdpi
On 18.08.2015 11:12, Milos Cuculovic - MDPI wrote:
Hi Aravinda,
I am using this version of glusterfs:
glusterfs 3.4.2 built on Jan 14 2014 18:05:35
Repository revision: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2013 Red Hat, Inc. <http://www.redhat.com/>
the status of the geo replication is OK:
NODE MASTER SLAVE STATUS
------------------------------------------------------------------
storage storage root@xxxxxxxxxxxxxxx:/data/data-cluster OK
So there are no issues with. Can it be that the changelog is big due to
the fact that he took a lot of time to do the 1st sync, so now he need
to run through all the changelogs?
In the log directory, I have two log files, in the 1st one, I have those
kind of logs:
[2015-08-18 04:39:57.331947] I [glusterfsd.c:1068:reincarnate]
0-glusterfsd: Fetching the volume file from server...
[2015-08-18 04:39:57.332500] I [glusterfsd-mgmt.c:1584:mgmt_getspec_cbk]
0-glusterfs: No change in volfile, continuing
[2015-08-18 04:39:57.343306] I [glusterfsd.c:1068:reincarnate]
0-glusterfsd: Fetching the volume file from server...
[2015-08-18 04:39:57.343651] I [glusterfsd-mgmt.c:1584:mgmt_getspec_cbk]
0-glusterfs: No change in volfile, continuing
In the second one, I was just geting some logs when trying to check the
file:
[2015-08-18 11:09:03.116003] E [syncdutils:174:log_raise_exception]
<top>: timestamp corruption for ./dms/molecules/molecules-19-15411
[2015-08-18 11:09:03.122987] I [syncdutils:148:finalize] <top>: exiting.
[2015-08-18 11:09:03.924904] I [monitor(monitor):21:set_state] Monitor:
new state: faulty
[2015-08-18 11:09:13.952065] I [monitor(monitor):80:monitor] Monitor:
------------------------------------------------------------
[2015-08-18 11:09:13.952385] I [monitor(monitor):81:monitor] Monitor:
starting gsyncd worker
[2015-08-18 11:09:14.14427] I [gsyncd:404:main_i] <top>: syncing:
gluster://localhost:storage ->
ssh://root@xxxxxxxxxxxxxxx:/data/data-cluster
[2015-08-18 11:09:20.49017] I [master:60:gmaster_builder] <top>: setting
up master for normal sync mode
[2015-08-18 11:09:21.303029] I [master:679:crawl] _GMaster: new master
is 00568bee-a211-4d0f-9ad4-918849f824d3
[2015-08-18 11:09:21.303330] I [master:683:crawl] _GMaster: primary
master with volume id 00568bee-a211-4d0f-9ad4-918849f824d3 ...
[2015-08-18 11:10:14.106652] I [monitor(monitor):21:set_state] Monitor:
new state: OK
It seems he has changed the status to faulty and was able to recover,
but what does this error means: "timestamp corruption for ..."
-- Kindest regards,
Milos Cuculovic
IT Manager
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
