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, lliu On Thu, Oct 17, 2013 at 4:08 PM, Roberto De Ioris <[email protected]> wrote: > >> hi Roberto, I did the experiments and got the following results. >> >> dbrg-dell720-2 is the master, it started with no problem: >> >> [dbrg@dbrg-dell720-2 ~]$ uwsgi --socket :4040 --cache2 >> name=master,items=100 --load-file-in-cache /etc/passwd >> *** Starting uWSGI 1.9.15-dev (64bit) on [Thu Oct 17 15:33:12 2013] *** >> compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 August >> 2013 13:02:23 >> os: Linux-2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 >> nodename: dbrg-dell720-2 >> machine: x86_64 >> clock source: unix >> pcre jit disabled >> detected number of CPU cores: 24 >> current working directory: /home/dbrg >> detected binary path: /usr/bin/uwsgi >> *** WARNING: you are running uWSGI without its master process manager *** >> your processes number limit is 1024 >> your memory page size is 4096 bytes >> detected max file descriptor number: 1024 >> lock engine: pthread robust mutexes >> *** Cache "master" initialized: 6MB (key: 2120 bytes, keys: 212000 >> bytes, data: 6553600 bytes, bitmap: 0 bytes) preallocated *** >> [cache] stored "/etc/passwd" in "master" >> uwsgi socket 0 bound to TCP address :4040 fd 4 >> Python version: 2.6.6 (r266:84292, Sep 12 2011, 14:03:14) [GCC 4.4.5 >> 20110214 (Red Hat 4.4.5-6)] >> *** Python threads support is disabled. You can enable it with >> --enable-threads *** >> Python main interpreter initialized at 0x24ac8d0 >> your server socket listen backlog is limited to 100 connections >> your mercy for graceful operations on workers is 60 seconds >> mapped 72776 bytes (71 KB) for 1 cores >> *** Operational MODE: single process *** >> *** no app loaded. going in full dynamic mode *** >> *** uWSGI is running in multiple interpreter mode *** >> spawned uWSGI worker 1 (and the only) (pid: 30982, cores: 1) >> >> ######################### >> dbrg-dell720-1 is the slave, it can not connect to the cache server >> >> [dbrg@dbrg-dell720-1 ~]$ uwsgi --socket :4041 --cache2 >> name=master,items=100,sync=127.0.0.1:4040 >> *** Starting uWSGI 1.9.15-dev (64bit) on [Thu Oct 17 15:33:47 2013] *** >> compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 August >> 2013 13:02:23 >> os: Linux-2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 >> nodename: dbrg-dell720-1 >> machine: x86_64 >> clock source: unix >> pcre jit disabled >> detected number of CPU cores: 24 >> current working directory: /home/dbrg >> detected binary path: /usr/sbin/uwsgi >> *** WARNING: you are running uWSGI without its master process manager *** >> your processes number limit is 1024 >> your memory page size is 4096 bytes >> detected max file descriptor number: 1024 >> lock engine: pthread robust mutexes >> *** Cache "master" initialized: 6MB (key: 2120 bytes, keys: 212000 >> bytes, data: 6553600 bytes, bitmap: 0 bytes) preallocated *** >> [cache-sync] getting cache dump from 127.0.0.1:4040 ... >> [cache-sync] unable to connect to the cache server >> >> ########################### >> but if I start the slave instance on master (dbrg-dell720-2) as well, >> it can restore the item. >> >> [dbrg@dbrg-dell720-2 ~]$ uwsgi --socket :4041 --cache2 >> name=master,items=100,sync=127.0.0.1:4040 >> *** Starting uWSGI 1.9.15-dev (64bit) on [Thu Oct 17 15:37:13 2013] *** >> compiled with version: 4.4.6 20110731 (Red Hat 4.4.6-3) on 29 August >> 2013 13:02:23 >> os: Linux-2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 >> nodename: dbrg-dell720-2 >> machine: x86_64 >> clock source: unix >> pcre jit disabled >> detected number of CPU cores: 24 >> current working directory: /home/dbrg >> detected binary path: /usr/bin/uwsgi >> *** WARNING: you are running uWSGI without its master process manager *** >> your processes number limit is 1024 >> your memory page size is 4096 bytes >> detected max file descriptor number: 1024 >> lock engine: pthread robust mutexes >> *** Cache "master" initialized: 6MB (key: 2120 bytes, keys: 212000 >> bytes, data: 6553600 bytes, bitmap: 0 bytes) preallocated *** >> [cache-sync] getting cache dump from 127.0.0.1:4040 ... >> [uwsgi-cache] restored 1 items >> uwsgi socket 0 bound to TCP address :4041 fd 4 >> Python version: 2.6.6 (r266:84292, Sep 12 2011, 14:03:14) [GCC 4.4.5 >> 20110214 (Red Hat 4.4.5-6)] >> *** Python threads support is disabled. You can enable it with >> --enable-threads *** >> Python main interpreter initialized at 0x1cf78e0 >> your server socket listen backlog is limited to 100 connections >> your mercy for graceful operations on workers is 60 seconds >> mapped 72776 bytes (71 KB) for 1 cores >> *** Operational MODE: single process *** >> *** no app loaded. going in full dynamic mode *** >> *** uWSGI is running in multiple interpreter mode *** >> spawned uWSGI worker 1 (and the only) (pid: 31057, cores: 1) >> >> >> why does the slave instance not work on slave node? any more hints? >> >> thanks, >> >> lliu >> > > > Sorry if i have not understood correctly, but if you are using different > nodes you cannot use 127.0.0.1 address, you have to use their network > addresses (not the loopback). > > I suppose this is why you did not get udp traffic too > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
