tt replicaset upgrade: support remote replica set

[mandesero]

This patch adds the ability to update the schema on a remote replica set.

---

Example

Start vshard app.

config.yaml

credentials:
  users:
    client:
      password: 'secret'
      roles: [super]
    replicator:
      password: 'secret'
      roles: [replication]
    storage:
      password: 'secret'
      roles: [sharding]

iproto:
  advertise:
    peer:
      login: replicator
    sharding:
      login: storage

sharding:
  bucket_count: 3000

groups:
  storages:
    app:
      module: storage
    sharding:
      roles: [storage]
    replication:
      failover: manual
    replicasets:
      storage-001:
        leader: storage-001-a
        instances:
          storage-001-a:
            iproto:
              listen:
                - uri: localhost:3301
          storage-001-b:
            iproto:
              listen:
                - uri: localhost:3302
      storage-002:
        leader: storage-002-a
        instances:
          storage-002-a:
            iproto:
              listen:
                - uri: localhost:3303
          storage-002-b:
            iproto:
              listen:
                - uri: localhost:3304
  routers:
    app:
      module: router
    sharding:
      roles: [router]
    replicasets:
      router-001:
        instances:
          router-001-a:
            iproto:
              listen:
                - uri: localhost:3305

To update the schema of this cluster, you need to update each replica set individually. Simply select one instance of each replica set and run:

$ tt replicates upgrade tcp://client:[email protected]:3301
  • storage-001: ok
$ tt replicates upgrade tcp://client:[email protected]:3304
  • storage-002: ok
$ tt replicates upgrade tcp://client:[email protected]:3305
  • router-001: ok

---

Closes #968

[mandesero]

tt/cli/replicaset/cmd/upgrade.go

Lines 152 to 165 in a1c2065

	if instance.Mode == replicaset.ModeUnknown {
	// Discovery cannot determine all instance modes of the remote replica set.
	res, err := conn.Eval(
	"return (type(box.cfg) == 'function') or box.info.ro",
	[]any{}, connector.RequestOpts{})
	if err != nil || len(res) == 0 {
	return nil, nil, fmt.Errorf(
	"can't determine RO/RW mode on instance: %s",
	fullInstanceName)
	}
	isRW = !res[0].(bool)
	} else {
	isRW = instance.Mode.String() == "rw"
	}

This point was already discussed (in the previous patch), but I found that the Discovery mechanism cannot determine the mode of all instances in a replica set (although it should) using the uri.

For example, I try to run tt replicates status to demonstrate the problem:

$ tt replicaset status tcp://client:[email protected]:3301
Orchestrator:      centralized config
Replicasets state: bootstrapped

• storage-001
  Failover: manual
    • storage-001-a localhost:3301 rw
    • storage-001-b localhost:3302 unknown

But it knows the correct address localhost:3302 to connect to this instance. I think this is a bug. Without the uri everything is fine:

$ tt replicaset status new-app:storage-001-a
Orchestrator:      centralized config
Replicasets state: bootstrapped

• router-001
  Failover: off
  Master:   single
    • router-001-a localhost:3305 rw
• storage-001
  Failover: manual
  Master:   single
    • storage-001-a localhost:3301 rw
    • storage-001-b localhost:3302 read
• storage-002
  Failover: manual
  Master:   single
    • storage-002-a localhost:3303 rw
    • storage-002-b localhost:3304 read

[oleg-jukovec]

Please rebase on the master branch.

[oleg-jukovec]

In such cases, we need to update the discovery code rather than create workrounds and spread it across the code.