ydbops reference sheet

ydbops options

DB connection options

DB connection options are described in Connecting to and authenticating with a database.

Service options

  • --verbose: increases output verbosity.

  • --profile-file: use profiles from the specified file. By default, profiles from the $HOME/ydb/ydbops/config/config.yaml file are used.

  • --profile <string>: override currently set profile name from --profile-file.

  • --grpc-timeout-seconds <int>: wait this much time in seconds before timing out any GRPC requests (default 60).

  • --grpc-skip-verify: do not verify server hostname when using gRPCs.

  • --ca-file <filepath>: path to root ca file, appends to system pool.

ydbops restart options

  • --storage: only include storage nodes. If no --storage or --tenant is specified, both --storage and --tenant become active, as it is assumed that the intention is to restart the whole cluster.

  • --tenant: only include tenant nodes. Additionally, you can specify:

    • --tenant-list=<tenant-name-1>,<tenant-name-2>
  • --availability-mode <strong|weak|force>: see the article about maintenance without downtime. Defaults to strong.

  • --restart-duration <int>: multiplied by --restart-retry-number, this gives the total duration in seconds for the maintenance operation. In other words, it is a promise to CMS that a single node restart will finish within given duration. Defaults to 60 (which makes the default CMS request duration 180 seconds in combination with the default value of --restart-retry-number)

  • --restart-retry-number <int>: if restarting a specific node failed, repeat the restart operation this much times. Defaults to 3.

  • --cms-query-interval <int>: how often to query for updates from CMS while waiting for new nodes. Defaults to 10 seconds.

  • --nodes-inflight <int>: the maximum number of nodes that are concurrently being restarted.

  • --delay-between-restarts <duration>: delay before initiating the next node restart.

Filtering options

Filtering options allow you to narrow down the list of nodes to restart.

  • --hosts <list>: restart the following hosts. Hosts can be specified in multiple ways:
    • Using node ids: --hosts=1,2,3
    • Using host fqdns: --hosts=<node1.some.zone>,<node2.some.zone>
  • --exclude-hosts <list>: do not restart the following hosts even if explicitly included. Syntax is the same as with the --hosts option.
  • --started '<sign><timestamp>': restart only the nodes that satisfy the particular uptime. Specify the sign (< or >) and a timestamp in ISO format to filter only the nodes that started before or after a particular timestamp. Be careful to enclose the timestamp with a sign in quotes, otherwise shell might interpret the sign as stream redirection.
    • example: ydbops restart --started '>2024-03-13T17:00:00Z'
  • --version '<sign><major>.<minor>.<patch>': restart only the nodes that satisfy the particular version filter. Specify the sign (<, >, != or ==), then specify the version by supplying three numbers: major, minor, patch versions. Be careful to enclose the timestamp with a sign in quotes, otherwise shell might interpret the sign as stream redirection.
    • example: ydbops restart --version '>24.3.1'
    • the command works with ydb processes that have their version in the following format: ydb-stable-<major>-<minor>-<patch>.*. Hotfix versions (e.g. ydb-stable-24-1-14-hotfix-9) have the same major, minor, patch numbers as their non-hotfix 24.1.14. For example, ydb-stable-24-1-14-hotfix-9 is treated in the same way as ydb-stable-24-1-14.

Kubernetes options

If --kubeconfig is specified, it is assumed that the cluster to be restarted runs under Kubernetes, and node restart will be achieved by deleting pods as opposed to other ways of restart (e.g. systemd units).

  • --kubeconfig: location to kubeconfig file which will be used for communicating with Kubernetes API (e.g. restarting nodes by deleting pods). There is no default value, since specifying this option also indicates Kubernetes mode.
  • --k8s-namespace: namespace where pods with storage or tenant processes are located. The usecase with nodes located in multiple namespaces is currently unsupported.
Previous
Next