Thank you for your answer...
Does using the NFS client insure replication to all bricks? My problem
is that I see Gluster has "unfinished" replication tasks that lie
around. Seems like the Gluster needs an external trigger to like "ls -l"
on the file in question to re-trigger and complete the replication if it
had failed (temporarily) for any reason.
I have solved the problem of making the application read from the "local
brick" by mounting the brick locally with -bind as read-only and making
my application separate reads from writes with different filesystem paths.
On 21/10/12 23.18, Israel Shirk wrote:
Haris, try the NFS mount. Gluster typically triggers healing through
the client, so if you skip the client, nothing heals.
The native Gluster client tends to be really @#$@#$@# stupid. It'll
send reads to Singapore while you're in Virginia (and there are bricks
0.2ms away), then when healing is needed it will take a bunch of time
to do that, all the while it's blocking your application or web
server, which under heavy loads will cause your entire application to
buckle.
The NFS client is dumb, which in my mind is a lot better - it'll just
do what you tell it to do and allow you to compensate for connectivity
issues yourself using something like Linux-HA.
You have to keep in mind when using gluster that 99% of the people
using it are running their tests on a single server (see the recent
notes about how testing patches are only performed on a single
server), and most applications don't distribute or mirror to bricks
more than a few hundred yards away. Their idea of geo-replication is
that you send your writes to the other side of the world (which may or
may not be up at the moment), then twiddle your thumbs for a while and
hope it gets back to you. So, that said, it's possible to get it to
work, and it's almost better than lsyncd, but it'll still make you cry
periodically.
Ok, back to happy time :)
Hi everyone,
I am using Gluster in replication mode.
Have 3 bricks on 3 different physical servers connected with WAN. This
makes writing but also reading files from Gluster mounted volume
very slow.
To remedy this I have made my web application read Gluster files from
the brick directly (I make a readonly bind mount of the brick), but
write to the Gluster FS mounted volume so that the files will
instantly
replicate on all 3 servers. At least, "instant replication" is what I
envision GLuster will do for me :)
My problem is that files sometimes do not replicate to all 3 servers
instantly. There are certainly short network outages which may prevent
instant replication and I have situations like this:
ssh web1-prod ls -l
/home/gluster/r/production/zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js
<http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js>
-rw-r--r-- 1 apache apache 75901 Oct 19 18:00
/home/gluster/r/production/zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js
<http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js>
web2-prod.
ssh web2-prod ls -l
/home/gluster/r/production/zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js
<http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js>
-rw-r--r-- 1 apache apache 0 Oct 19 18:00
/home/gluster/r/production/zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js
<http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js>
web3-prod.
ssh web3-prod ls -l
/home/gluster/r/production/zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js
<http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js>
-rw-r--r--. 1 apache apache 75901 Oct 19 18:00
/home/gluster/r/production/zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js
<http://zdrava.tv/web/uploads/24/playlist/38/19_10_2012_18.js>
Where the file on web2 server brick has a size of 0. So serving this
file from web2 makes my application make errors..
I have had a brain-split situation couple of times and resolved
manually. The above kind of situation is not a brain-split and
resolves
and (re-)replicates completly with a simple "ls -l" on the file in
question from any of the servers.
My question is:
I suppose that the problem here is incomplete replication for the file
in question due to temporary network problems.
How to insure the complete replication immediatly after the
network has
been restored?
kind regards
Haris Zukanovic
--
--
Haris Zukanovic
--
--
Haris Zukanovic
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
