谢谢， 集群正在恢复了。
有个疑问，如果replicas不能少于3， 为何不在强制无法设置少于3？
如果完全按照官网的推荐来来配置，那成本太高， 很可能一开始就无法在公司推广使用，例如我们目前的情况是1G的网卡，数据库机器统一的普通的ssd做的raid5, 要上线tidb得从交换机，机器到硬盘全部换， 在还没有试用得到验证前，很难以这样的标准来搭建tidb集群。我们一接入就十几T的数据，每天好几千万的数据同步到tidb , 需要的成本过大， 我熟悉的另一个细分行业的龙头公司也因为成本问题而不再推广使用。
我一开始是把sync-log设置了为true, 但写入太慢了，OPS达不到官方的要求， 只能设置为false. 我们认为丢一两分钟的数据并没有问题，我们只需要把dm同步的mysql binlog位置点提前几分钟，重复同步这几分钟的数据就行。但目前的情况是，挂了节点了后， 因为region 丢失了，很可能很久以前的数据都没了，只能整个集群的数据重新同步，这代价与时间太大。就算设置了replica为3, 那也可能挂2台甚至多台机器，而导致丢失数据，需要整个集群重新同步。所以希望能够允许丢失部分最新的数据，让tikv 能够正常启动， 集群恢复正常。 灾难恢复只能恢复不定时间的数据，其实跟整个集群的数据都丢失了差不多， 很难接受挽救回来的数据在时间分布上是零散的。
希望能增加让有问题的tikv 能够强制起来的参数或者功能， 集群增加强制剩下的region能够直接提升为master的功能，让集群迅速恢复正常。 丢失最近几分钟甚至几小时的数据，大家基本都没啥问题，可以快速补回数据，但丢失的数据时间是不确定的，分布零散的，那基本没人能接受。