是否支持slave宕机转向Master呢？

[baiwfg2]

gdb 日志：

Core was generated by `./cerberus example.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 0x0000003a47432625 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003a47432625 in raise () from /lib64/libc.so.6
#1 0x0000003a47433e05 in abort () from /lib64/libc.so.6
#2 0x0000003a4a46007d in __gnu_cxx::__verbose_terminate_handler () at ../../.././libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x0000003a4a45e0e6 in __cxxabiv1::__terminate (handler=) at ../../.././libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x0000003a4a45e131 in std::terminate () at ../../.././libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x00000000005236ff in std::thread::~thread() ()
#6 0x0000000000523be2 in std::default_deletestd::thread::operator()(std::thread*) const ()
#7 0x00000000005253a9 in std::unique_ptr<std::thread, std::default_deletestd::thread >::~unique_ptr() ()
#8 0x0000000000525250 in util::sptrstd::thread::~sptr() ()
#9 0x0000000000526976 in cerb::ListenThread::~ListenThread() ()
#10 0x000000000052699c in void std::_Destroycerb::ListenThread(cerb::ListenThread*) ()
#11 0x000000000052693a in void std::_Destroy_aux::__destroycerb::ListenThread*(cerb::ListenThread*, cerb::ListenThread*) ()
#12 0x0000000000526912 in void std::_Destroycerb::ListenThread*(cerb::ListenThread*, cerb::ListenThread*) ()
#13 0x00000000005268ed in void std::_Destroy<cerb::ListenThread*, cerb::ListenThread>(cerb::ListenThread*, cerb::ListenThread*, std::allocatorcerb::ListenThread&) ()
#14 0x00000000005268a9 in std::vector<cerb::ListenThread, std::allocatorcerb::ListenThread >::~vector() ()
#15 0x0000003a47435b22 in exit () from /lib64/libc.so.6
#16 0x000000000052772d in (anonymous namespace)::exit_on_int(int) ()
#17
#18 0x0000003a478082fb in pthread_join () from /lib64/libpthread.so.0
#19 0x0000003a4a4bb627 in __gthread_join (__value_ptr=0x0, __threadid=)
at /root/tmp/gcc-4.9.3/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:668
#20 std::thread::join (this=) at ../../../.././libstdc++-v3/src/c++11/thread.cc:107
#21 0x00000000005224b0 in cerb::ListenThread::join() ()
#22 0x000000000052828e in (anonymous namespace)::run((anonymous namespace)::Configuration const&) ()
#23 0x0000000000528839 in main ()

个人认为由cerb_global::all_threads是全局变量所致，ctrl+c导致exit被调用， vector调用析构，而此时线程并未结束。建议将all_threads存储ListenThread指针而非ListenThread对象，当然也可去掉捕获SIGINT信号以消除此dump. 作者以为如何？

[zheplusplus]

控制线程结束略麻烦. 反正已经 ctrl-c 了, 挂了就挂了吧 ╮(╯▽╰)╭

[baiwfg2]

(⊙ｏ⊙)

[baiwfg2]

当read_slave yes时，如果slave宕机，会转向master吗？转向master一小段时间后，slave恢复了，能再转回来吗？

[zheplusplus]

会啊, 但是 slave 重新上线了不会再自动转回来. 可以手动发一个 UPDATESLOTMAP 命令转回来.

[baiwfg2]

嗯。当一个Node宕机时，会创建n个SlotsMapUpdator连接，都发cluster nodes命令重新获取槽分配，这种策略是必须这样还是为了方便起见呢？因为感觉只要连上一个发cluster nodes就行，干嘛要连这么多个，毕竟连了之后又会很快析构掉

[zheplusplus]

只选一个 updater 的话, 有可能恰好这个节点挂了或者这个节点从集群里退出了.

[baiwfg2]

如果proxy thread数目较大，则一旦有node宕机，就会造成每个proxy线程都在做update操作，感觉有点耗资源呢。如果把Update slot功能放到一个单独的线程或临时的进程里，而proxy线程共享一static SlotMap，这样是否会好些呢？可能增加了锁的开销，不过好像也只需在发生failover时才加锁，其他时候各线程都是在读