ES6.3.1升级ES7.3.1后，双节点集群工作正常，停掉master节点后，slave节点不能独立工作，一直尝试通信master节点

1，服务器：x86_64 x86_64 x86_64 GNU/Linux，双节点(log1和log2)，小网通信
2，软件版本：elasticsearch7.3.1，不带x-pack增强功能
3，工作模式：既作为master候选节点，也作为数据节点，log1的主分片在自己这，副本分片在log2那里，log2同理
4，elasticsearch.yml配置：除名称外两节点一致
cluster.name: log-search-cluster
node.name: node_20.23.72.14
path.data: /var/share/oss/CloudVPN/LogConfigService/es
path.logs: /opt/oss/log/CloudVPN/LogConfigService/es
bootstrap.memory_lock: true
network.host: 20.23.72.14
transport.tcp.port: 27336
discovery.zen.ping_timeout: 60s
client.transport.ping_timeout: 60s
cluster.join.timeout: 30s 
discovery.seed_hosts: [20.23.72.15, 20.23.72.14]
cluster.initial_master_nodes: [node_20.23.72.15, node_20.23.72.14]
5，上下文信息：
背景：ES6.3.1全部重启升级至ES7.3.1后，非滚动升级方式
当前运行状况：
      1，双节点集群模式：双节点集群工作正常，每个节点48个分片，主1备1，副本分片置于另一个节点上，数据一致，无异常
      2，双节点有一个停止运行：
           A，如果slave节点挂掉，master节点正常运行，单节点集群正常工作，可搜索、写入
           B,   如果master节点挂掉，slave节点工作不正常，会一直尝试重连原先的master节点，导致功能阻塞（想让slave节点升级             为master节点，单节点正常工作，一旦原master恢复，原来的master变成slave节点加入集群）
在ES6中如何处理的：
        通过人为控制discovery.zen.minimum_master_nodes该参数，实现双节点可集群工作，可单节点（master和slave都支持）独立工作。双节点集群时，该数目为2，达到投票数选出master节点，正常工作；单个节点时，该数目变为1，达到投票数，自己成为master节点，主分片正常运行，副本分片未分配，但功能正常，这就是我想要的效果！
ES7中如何处理的：
        移除原有的zen集群发现模块，引入新的集群协调子系统，discovery.zen.minimum_master_nodes的配置被忽略，不再生效，由ES自己选择可以形成仲裁的节点，导致当前主节点挂掉后，投票数不够，选不出Master节点，阻塞功能正常运行，然后一直尝试重连原来的master节点！
6，问题描述：
es升级前，双节点既可以集群工作，也可以独立节点工作（无论master还是slave节点），移除/加入节点，工作模式会动态变更
es升级后，双节点集群工作正常，master节点可独立工作，slave节点一直尝试重连master节点，功能阻塞(重启slave节点是可以独立运行的，但我不希望重启)，我希望slave节点在几次连接失败后，直接推选自己为master节点，独立节点工作，保证异常场景下功能正常。
7，联系邮箱：
15195895896@163.com
求助大神帮忙！