*: support clustering

[xhebox]

Signed-off-by: xhe xw897002528@gmail.com

What problem does this PR solve?

Issue Number: ref #69

Problem Summary: Support a cluster of tiproxy nodes.

What is changed and how it works: Add five new cmd flags.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)

n1: 3080,3081,6000
n2: 4080,4081,7000

 rm -rf work && ./bin/tiproxy --node_name=n1 --bootstrap_clusters "n2=127.0.0.1:4081" --config conf/proxy.yaml
rm -rf work2 && ./bin/tiproxy --node_name=n2 --bootstrap_clusters "n1=127.0.0.1:3081" --config conf2/proxy.yaml

After bootstraping

stop one node and restart it by ./bin/tiproxy  --config conf/proxy.yaml

• No code

Notable changes

• Has configuration change
• Has HTTP API interfaces change (Don't forget to add the declarative for API)
• Has tiproxyctl change
• Other user behavior changes

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[djshow832]

Why make it so complicated, are other components also like this?

[xhebox]

This is common for etcd and other cloud native applications. Other pingcap components relies on the central PD(they only need PD).

PD only provide bootstrapClusters options, and a sugar option of bootstrapCluster by -join xxx:2380 if you don't want to write all clusters by hands. I have no plan to include that sugar option in this PR.

Honestly, discovery or dns is more convenient.

To use --initial-clusters, you need to specify all nodes. To use -join, the cluster must be bootstraped already. Whatever you need to pass different options fot different PD and probably follow some orders(-join).

Operator has implemented some very complex code. But I hope I can start all tiproxy nodes by some etcd discovery like ./bin/tiproxy --bootstrap-discovery-etcd xxxx.

[djshow832]

In my option, there's even no need to merge this PR, right? Proxies don't need to know each other, except for updating configurations. But updating configurations can be achieved by configuring the etcd address.

[xhebox]

We have no etcd address. Tiproxy itself is a etcd server.

Unless you want a 'master tiproxy node' explicitly, again you need you need to first bootstrap a central single-node cluster. Other nodes need to -central-etcd xxx.

Or if you want to propagate global configurations to every node manually by tiproxyctl. For example, tls certs, namespace/routing/filter rules.

[xhebox]

Only if you want to remove etcd from tiproxy, and relies on an external ETCD. I think it makes things complicated. If you have PD, you don't want another etcd. If you use tiproxy with static servers, you need another etcd.