> yes, the master and slave are two different servers. the updates can > be propagated to slave after I use the following settings: > > on master (ip=10.1.1.11): > cache2 = > name=test-conf-cache,items=8192,blocksize=2048,store=/shared_disk/test_cache2.dump,nodes=10.1.1.12:7172,udp=10.1.1.11:7171 > > and on slave (ip=10.1.1.12): > cache2 = > name=test-conf-cache,items=8192,blocksize=2048,store=/shared_disk/test_cache2.dump,udp=10.1.1.12:7172 > > now everything seems alright. but i am wondering if there will be some > problem in the future since you mentioned that i should not use the > store=/shared_disk/test_cache2.dump as a part of the config on slave > node. I tried setting sync, but failed. In fact, i cannot make the > master as a cache2 sync server because it works behind nginx via unix > sockets. The slave node cannot connect to the sync server whatever > sync address i set. So i guess to restore the initial data from a file > on shared disk is my only choice. Is this setting risky? what do you > think? > > thanks, >
The problem is that if you sync while an update is in place you could get an inconsistent cache image. I would try understanding why sync=<node> does not work for the slave. Remember that sync happens via tcp so the <node> address is the same value of --socket of the uwsgi instance -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
