Hi Cedric,
Any file is picked up for signing by the bitd process after the
predetermined wait of 120 seconds. This default value is captured in the
volume option 'features.expiry-time' and is configurable - in your case,
it can be set to 0 or 1.
Point 2 is correct. A file corrupted before th
Bitrot has a scrub process which detects the corrupted file. Once
detected, it is the prerogative of the user to follow the sequence of
steps [1] to trigger a heal. Having said that, client access to that
file is not impacted as it continues to serve data from the good copy.
Steps remain the sa
Hi Milos,
If I get this correctly, this is your configuration below:
* Geo-rep master- Europe
* Geo-rep slave - Asia
* Same web application installed, and users from Asia are redirected to
slave (in Asia), users from rest of the world are directed to master (in
Europe)
And you want read/write
Hi Milos,
If I get this correctly, this is your configuration below:
* Geo-rep master- Europe
* Geo-rep slave - Asia
* Same web application installed, and users from Asia are redirected to
slave (in Asia), users from rest of the world are directed to master (in
Europe)
And you want read/writ
Hi Shyam,
Were the peers in a connected state anytime *before*?
If yes, then these are the things you can do to troubleshoot and get the
cluster back to normal (some of which Neils has already mentioned ):
1. Check if the nodes are reachable.. 'ping '
2. Check if the glusterd daemon is in an
