I don??t think exit is a good solution (even if you use multiple intermittent retries).
I think the original design is better. I also have a reply in this issue #4226. When the upstream is abnormal ( The downstream is strongly dependent on the upstream), our better approach is to adopt a circuit breaker strategy instead of directly downgrading. The original method (sleep is actually a means of circuit breakers) The problem we need to focus on is how to reduce logs, not stop services. Best wishes?? CalvinKirs On 12/30/2020 15:27????????<[email protected]> wrote?? Dear all 1) In the current version, there is a dead loop, one second for each sleep: if the database fails, the master will always print the log. The disadvantage is that it is easy to fill up the disk. The advantage is that the service can be restored after the database is restored. 2) Allows users to set the number of consecutive database connection failures, the default value is - 1 (that is unlimited number). If the maximum number of database connection failures is reached, the master exits the service. The advantage is that the maximum number of logs can be controlled. The disadvantage is that if the number of consecutive database connection failures exceeds the maximum number of database connection failures, the master will exit and the service cannot be restored after the database is restored. 1) ????????,????????????????1????????????????????master???????????????????????????????????????????????????????????????????????????????? 2) ????????????????????????????????????????????-1??????????????????????????????????????????????????????master?????????????????????????????????????????????????? ????????????????????????????????????????????????????????????master???????????????????????????????????? liukunyuan
