Version: release-0.9

Manage Qdrant with KubeBlocks

The popularity of generative AI (Generative AI) has aroused widespread attention and completely ignited the vector database (Vector Database) market. Qdrant (read: quadrant) is a vector similarity search engine and vector database. It provides a production-ready service with a convenient API to store, search, and manage points—vectors with an additional payload Qdrant is tailored to extended filtering support. It makes it useful for all sorts of neural-network or semantic-based matching, faceted search, and other applications.

KubeBlocks supports the management of Qdrant. This tutorial illustrates how to create and manage a Qdrant cluster by kbcli, kubectl or a YAML file. You can find the YAML examples in the GitHub repository.

Before you start

Install kbcli if you want to manage the Qdrant cluster with kbcli.
Install KubeBlocks by kbcli or by Helm.
Install and enable the Qdrant Addon by kbcli or by Helm.
To keep things isolated, create a separate namespace called demo throughout this tutorial.
```
kubectl create namespace demo
```

Create a cluster

Steps

kbcli
kubectl

Execute the following command to create a Qdrant cluster.
```
kbcli cluster create qdrant mycluster -n demo
```
If you want to customize your cluster specifications, kbcli provides various options, such as setting cluster version, termination policy, CPU, and memory. You can view these options by adding --help or -h flag.
```
kbcli cluster create qdrant --help

kbcli cluster create qdrant -h
```

Check whether the cluster is created.

kbcli cluster list -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION        TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        qdrant                              Delete               Running   Aug 15,2023 23:03 UTC+0800

Check the cluster information.

kbcli cluster describe mycluster -n demo
>
Name: mycluster         Created Time: Aug 15,2023 23:03 UTC+0800
NAMESPACE   CLUSTER-DEFINITION   VERSION        STATUS    TERMINATION-POLICY
demo        qdrant                              Running   Delete

Endpoints:
COMPONENT   MODE        INTERNAL                                                 EXTERNAL
qdrant      ReadWrite   mycluster-qdrant-qdrant.default.svc.cluster.local:6333   <none>
                        mycluster-qdrant-qdrant.default.svc.cluster.local:6334

Topology:
COMPONENT   INSTANCE             ROLE     STATUS    AZ       NODE                   CREATED-TIME
qdrant      mycluster-qdrant-0   <none>   Running   <none>   x-worker3/172.20.0.3   Aug 15,2023 23:03 UTC+0800
qdrant      mycluster-qdrant-1   <none>   Running   <none>   x-worker2/172.20.0.5   Aug 15,2023 23:03 UTC+0800
qdrant      mycluster-qdrant-2   <none>   Running   <none>   x-worker/172.20.0.2    Aug 15,2023 23:04 UTC+0800

Resources Allocation:
COMPONENT   DEDICATED   CPU(REQUEST/LIMIT)   MEMORY(REQUEST/LIMIT)   STORAGE-SIZE   STORAGE-CLASS
qdrant      false       1 / 1                1Gi / 1Gi               data:20Gi      standard

Images:
COMPONENT   TYPE     IMAGE
qdrant      qdrant   docker.io/qdrant/qdrant:latest

Data Protection:
AUTO-BACKUP   BACKUP-SCHEDULE   TYPE     BACKUP-TTL   LAST-SCHEDULE   RECOVERABLE-TIME
Disabled      <none>            <none>   7d           <none>          <none>

Show cluster events: kbcli cluster list-events -n demo mycluster

KubeBlocks implements a Cluster CRD to define a cluster. Here is an example of creating a Qdrant Replication cluster. Primary and Secondary are distributed on different nodes by default. But if you only have one node for deploying a Replication Cluster, set spec.affinity.topologyKeys as null.

cat <<EOF | kubectl apply -f -
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: qdrant
  clusterVersionRef: qdrant-1.8.1
  terminationPolicy: Delete
  affinity:
    podAntiAffinity: Preferred
    topologyKeys:
    - kubernetes.io/hostname
  tolerations:
    - key: kb-data
      operator: Equal
      value: 'true'
      effect: NoSchedule
  componentSpecs:
  - name: qdrant
    componentDefRef: qdrant
    disableExporter: true
    serviceAccountName: kb-mycluster
    replicas: 2
    resources:
      limits:
        cpu: '0.5'
        memory: 0.5Gi
      requests:
        cpu: '0.5'
        memory: 0.5Gi
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
EOF

Field	Definition
`spec.clusterDefinitionRef`	It specifies the name of the ClusterDefinition for creating a specific type of cluster.
`spec.clusterVersionRef`	It is the name of the cluster version CRD that defines the cluster version.
`spec.terminationPolicy`	It is the policy of cluster termination. The default value is `Delete`. Valid values are `DoNotTerminate`, `Halt`, `Delete`, `WipeOut`. - `DoNotTerminate` blocks deletion operation. - `Halt` deletes workload resources such as statefulset and deployment workloads but keep PVCs. - `Delete` is based on Halt and deletes PVCs. - `WipeOut` is based on Delete and wipe out all volume snapshots and snapshot data from a backup storage location.
`spec.affinity`	It defines a set of node affinity scheduling rules for the cluster's Pods. This field helps control the placement of Pods on nodes within the cluster.
`spec.affinity.podAntiAffinity`	It specifies the anti-affinity level of Pods within a component. It determines how pods should spread across nodes to improve availability and performance.
`spec.affinity.topologyKeys`	It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.
`spec.tolerations`	It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.
`spec.componentSpecs`	It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.
`spec.componentSpecs.componentDefRef`	It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition qdrant -o json \\| jq '.spec.componentDefs[].name'`.
`spec.componentSpecs.name`	It specifies the name of the component.
`spec.componentSpecs.disableExporter`	It defines whether the monitoring function is enabled.
`spec.componentSpecs.replicas`	It specifies the number of replicas of the component.
`spec.componentSpecs.resources`	It specifies the resource requirements of the component.

KubeBlocks operator watches for the Cluster CRD and creates the cluster and all dependent resources. You can get all the resources created by the cluster with kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo.

kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo

Run the following command to see the created Qdrant cluster object:

kubectl get cluster mycluster -n demo -o yaml

Connect to a Qdrant cluster

Qdrant provides both HTTP and gRPC protocols for client access on ports 6333 and 6334 respectively. Depending on where the client is, different connection options are offered to connect to the Qdrant cluster.

kbcli
Port forward

note

If your cluster is on AWS, install the AWS Load Balancer Controller first.

If your client is inside a K8s cluster, run kbcli cluster describe mycluster -n demo to get the ClusterIP address of the cluster or the corresponding K8s cluster domain name.
If your client is outside the K8s cluster but in the same VPC as the server, run kbcli cluster expose mycluster -n demo --enable=true --type=vpc to get a VPC load balancer address for the database cluster.
If your client is outside the VPC, run kbcli cluster expose mycluster -n demo --enable=true --type=internet to open a public network reachable address for the database cluster.

Run the following command to port forward the service.

kubectl port-forward svc/mycluster-qdrant 6333:6333 -n demo

Open a new terminal and run the following command to connect to the database.
```
curl http://127.0.0.1:6333/collections
```
Refer to the official Qdrant documents for the cluster operations.

Monitor the database

The monitoring function of Qdrant is the same as other engines. For details, refer to the monitoring tutorial.

Scale

The scaling function for Qdrant is also supported.

Scale horizontally

Horizontal scaling changes the amount of pods. For example, you can scale out replicas from three to five.

From v0.9.0, besides replicas, KubeBlocks also supports scaling in and out instances, refer to Horizontal Scale in API docs for more details and examples.

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kbcli
kubectl

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION   TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        qdrant                         Delete               Running   Aug 15,2023 23:03 UTC+0800

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION        TERMINATION-POLICY     STATUS    AGE
mycluster   qdrant                              Delete                 Running   47m

Steps

kbcli
OpsRequest
Edit cluster YAML file

Set the --replicas value according to your needs and perform the horizontal scaling.
```
kbcli cluster hscale mycluster -n demo --replicas=5 --components=qdrant
```
- --components describes the component name ready for horizontal scaling.
- --replicas describes the replica amount of the specified components. Edit the amount based on your demands to scale in or out replicas.
Please wait a few seconds until the scaling process is over.
Validate the horizontal scaling operation.
- View the OpsRequest progress.
  KubeBlocks outputs a command automatically for you to view the OpsRequest progress. The output includes the status of this OpsRequest and Pods. When the status is Succeed, this OpsRequest is completed.
```
kbcli cluster describe-ops mycluster-horizontalscaling-xpdwz -n demo
```
- View the cluster satus.
```
kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION   TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        qdrant                         Delete               Running   Jul 24,2023 11:38 UTC+0800
```
  - STATUS=Updating: it means horizontal scaling is in progress.
  - STATUS=Running: it means horizontal scaling has been applied.
After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.
```
kbcli cluster describe mycluster -n demo
```

Apply an OpsRequest to a specified cluster. Configure the parameters according to your needs.

The example below means adding two replicas.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-horizontal-scaling
  namespace: demo
spec:
  clusterName: mycluster
  type: HorizontalScaling
  horizontalScaling:
  - componentName: qdrant
    scaleOut:
      replicaChanges: 2
EOF

If you want to scale in replicas, replace scaleOut with scaleIn.

The example below means deleting two replicas.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-horizontal-scaling
  namespace: demo
spec:
  clusterName: mycluster
  type: HorizontalScaling
  horizontalScaling:
  - componentName: qdrant
    scaleIn:
      replicaChanges: 2
EOF

Check the operation status to validate the horizontal scaling status.

kubectl get ops -n demo
>
NAMESPACE   NAME                     TYPE                CLUSTER     STATUS    PROGRESS   AGE
demo        ops-horizontal-scaling   HorizontalScaling   mycluster   Succeed   3/3        6m

If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Change the configuration of spec.componentSpecs.replicas in the YAML file. spec.componentSpecs.replicas stands for the pod amount and changing this value triggers a horizontal scaling of a cluster.

kubectl edit cluster mycluster -n demo
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: qdrant
  clusterVersionRef: qdrant-1.8.1
  componentSpecs:
  - name: qdrant
    componentDefRef: qdrant
    replicas: 2 # Change the amount
......

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Scale vertically

You can vertically scale a cluster by changing resource requirements and limits (CPU and storage). For example, you can change the resource class from 1C2G to 2C4G by performing vertical scaling.

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kbcli
kubectl

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION   TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        qdrant                         Delete               Running   Aug 15,2023 23:03 UTC+0800

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION        TERMINATION-POLICY     STATUS    AGE
mycluster   qdrant                              Delete                 Running   47m

Steps

kbcli
OpsRequest
Edit cluster YAML file

Set the --cpu and --memory values according to your needs and run the following command to perform vertical scaling.
```
kbcli cluster vscale mycluster -n demo --cpu=0.5 --memory=512Mi --components=qdrant 
```
Please wait a few seconds until the scaling process is over.
Validate the vertical scaling operation.
- View the OpsRequest progress.
  KubeBlocks outputs a command automatically for you to view the OpsRequest progress. The output includes the status of this OpsRequest and Pods. When the status is Succeed, this OpsRequest is completed.
```
kbcli cluster describe-ops mycluster-verticalscaling-rpw2l -n demo
>
NAME                              TYPE              CLUSTER      STATUS    PROGRESS   AGE
mycluster-verticalscaling-rpw2l   VerticalScaling   mycluster    Running   1/5        44s
```
- Check the cluster status.
```
kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION           TERMINATION-POLICY   STATUS     CREATED-TIME
mycluster   demo                                               Delete               Updating   Aug 15,2023 23:03 UTC+0800
```
  - STATUS=Updating: it means the vertical scaling is in progress.
  - STATUS=Running: it means the vertical scaling operation has been applied.
  - STATUS=Abnormal: it means the vertical scaling is abnormal. The reason may be that the number of the normal instances is less than that of the total instance or the leader instance is running properly while others are abnormal.
    To solve the problem, you can manually check whether this error is caused by insufficient resources. Then if AutoScaling is supported by the Kubernetes cluster, the system recovers when there are enough resources. Otherwise, you can create enough resources and troubleshoot with kubectl describe command.
After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.
```
kbcli cluster describe mycluster -n demo
```

Apply an OpsRequest to the specified cluster. Configure the parameters according to your needs.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-vertical-scaling
  namespace: demo
spec:
  clusterName: mycluster
  type: VerticalScaling
  verticalScaling:
  - componentName: qdrant
    requests:
      memory: "2Gi"
      cpu: "1"
    limits:
      memory: "4Gi"
      cpu: "2"
EOF

Check the operation status to validate the vertical scaling.

kubectl get ops -n demo
>
NAMESPACE   NAME                   TYPE              CLUSTER     STATUS    PROGRESS   AGE
demo        ops-vertical-scaling   VerticalScaling   mycluster   Succeed   3/3        6m

If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Change the configuration of spec.componentSpecs.resources in the YAML file. spec.componentSpecs.resources controls the requirement and limit of resources and changing them triggers a vertical scaling.

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: qdrant
  clusterVersionRef: qdrant-1.8.1
  componentSpecs:
  - name: qdrant
    componentDefRef: qdrant
    replicas: 1
    resources: # Change the values of resources.
      requests:
        memory: "2Gi"
        cpu: "1"
      limits:
        memory: "4Gi"
        cpu: "2"
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
  terminationPolicy: Delete

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Volume Expansion

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kbcli
kubectl

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION   TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        qdrant                         Delete               Running   Aug 15,2023 23:03 UTC+0800

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION        TERMINATION-POLICY     STATUS    AGE
mycluster   qdrant                              Delete                 Running   47m

Steps

kbcli
OpsRequest
Edit cluster YAML file

Set the --storage value according to your need and run the command to expand the volume.
```
kbcli cluster volume-expand mycluster -n demo --storage=40Gi --components=qdrant -t data
```
The volume expansion may take a few minutes.

Validate the volume expansion operation.

View the OpsRequest progress.

KubeBlocks outputs a command automatically for you to view the details of the OpsRequest progress. The output includes the status of this OpsRequest and PVC. When the status is Succeed, this OpsRequest is completed.

kbcli cluster describe-ops mycluster-volumeexpansion-5pbd2 -n demo
>
NAME                              TYPE              CLUSTER      STATUS   PROGRESS   AGE
mycluster-volumeexpansion-5pbd2   VolumeExpansion   mycluster    Running  1/1        67s

View the cluster status.

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION           TERMINATION-POLICY   STATUS     CREATED-TIME
mycluster   demo        qdrant                                 Delete               Updating   Aug 15,2023 23:03 UTC+0800

STATUS=Updating: it means the volume expansion is in progress.
STATUS=Running: it means the volume expansion operation has been applied.

After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.
```
kbcli cluster describe mycluster -n demo
```

Change the value of storage according to your need and run the command below to expand the volume of a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-volume-expansion
  namespace: demo
spec:
  clusterName: mycluster
  type: VolumeExpansion
  volumeExpansion:
  - componentName: qdrant
    volumeClaimTemplates:
    - name: data
      storage: "40Gi"
EOF

Validate the volume expansion operation.

kubectl get ops -n demo
>
NAMESPACE   NAME                   TYPE              CLUSTER     STATUS    PROGRESS   AGE
demo        ops-volume-expansion   VolumeExpansion   mycluster   Succeed   3/3        6m

If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

Check whether the corresponding cluster resources change.
```
kubectl describe cluster mycluster -n demo
```

Change the value of spec.componentSpecs.volumeClaimTemplates.spec.resources in the cluster YAML file.

spec.componentSpecs.volumeClaimTemplates.spec.resources is the storage resource information of the pod and changing this value triggers the volume expansion of a cluster.

kubectl edit cluster mycluster -n demo
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: qdrant
  clusterVersionRef: qdrant-1.8.1
  componentSpecs:
  - name: qdrant
    componentDefRef: qdrant
    replicas: 2
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi # Change the volume storage size.
  terminationPolicy: Delete

Check whether the corresponding cluster resources change.
```
kubectl describe cluster mycluster -n demo
```

Restart

kbcli
OpsRequest

Configure the values of components and ttlSecondsAfterSucceed and run the command below to restart a specified cluster.
```
kbcli cluster restart mycluster -n demo --components="qdrant" --ttlSecondsAfterSucceed=30
```
- components describes the component name that needs to be restarted.
- ttlSecondsAfterSucceed describes the time to live of an OpsRequest job after the restarting succeeds.

Validate the restarting.

Run the command below to check the cluster status to check the restarting status.

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION     VERSION         TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        qdrant                                 Delete               Running   Aug 15,2023 23:03 UTC+0800

STATUS=Updating: it means the cluster restart is in progress.
STATUS=Running: it means the cluster has been restarted.

Restart a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-restart
  namespace: demo
spec:
  clusterName: mycluster
  type: Restart 
  restart:
  - componentName: qdrant
EOF

Check the pod and operation status to validate the restarting.
```
kubectl get pod -n demo
kubectl get ops ops-restart -n demo
```
During the restarting process, there are two status types for pods.
- STATUS=Terminating: it means the cluster restart is in progress.
- STATUS=Running: it means the cluster has been restarted.

Stop/Start a cluster

You can stop/start a cluster to save computing resources. When a cluster is stopped, the computing resources of this cluster are released, which means the pods of Kubernetes are released, but the storage resources are reserved. You can start this cluster again by snapshots if you want to restore the cluster resources.

Stop a cluster

Configure the name of your cluster and run the command below to stop this cluster.

kbcli
OpsRequest
Edit cluster YAML file

kbcli cluster stop mycluster -n demo

Configure replicas as 0 to delete pods.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-stop
  namespace: demo
spec:
  clusterName: mycluster
  type: Stop
EOF

Edit the cluster YAML file and configure replicas as 0 to delete pods.

kubectl edit cluster mycluster -n demo
>
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
    name: mycluster
    namespace: demo
spec:
  clusterDefinitionRef: qdrant
  clusterVersionRef: qdrant-1.8.1
  terminationPolicy: Delete
  componentSpecs:
  - name: qdrant
    componentDefRef: qdrant
    disableExporter: true  
    replicas: 0
......

Check the status of the cluster to see whether it is stopped.

kbcli
kubectl

kbcli cluster list mycluster -n demo

kubectl get cluster mycluster -n demo

Start a cluster

Configure the name of your cluster and run the command below to start this cluster.

kbcli
OpsRequest
Edit cluster YAML file

kbcli cluster start mycluster -n demo

Run the command below to start a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-start
  namespace: demo
spec:
  clusterName: mycluster
  type: Start
EOF 

Change replicas back to the original amount to start this cluster again.

kubectl edit cluster mycluster -n demo
>
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
    name: mycluster
    namespace: demo
spec:
  clusterDefinitionRef: qdrant
  clusterVersionRef: qdrant-1.8.1
  terminationPolicy: Delete
  componentSpecs:
  - name: qdrant
    componentDefRef: qdrant
    disableExporter: true  
    replicas: 1
......

Check the status of the cluster to see whether it is running again.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
kubectl get cluster mycluster -n demo

Backup and restore

The backup and restore operations for Qdrant are the same as those of other clusters and you can refer to the backup and restore documents for details. Remember to use --method parameter.

Manage Qdrant with KubeBlocks

Before you start​

Create a cluster​

Connect to a Qdrant cluster​

Monitor the database​

Scale​

Scale horizontally​

Before you start​

Steps​

Scale vertically​

Before you start​

Steps​

Volume Expansion​

Before you start​

Steps​

Restart​

Stop/Start a cluster​

Stop a cluster​

Start a cluster​

Backup and restore​

Before you start

Create a cluster

Connect to a Qdrant cluster

Monitor the database

Scale

Scale horizontally

Before you start

Steps

Scale vertically

Before you start

Steps

Volume Expansion

Before you start

Steps

Restart

Stop/Start a cluster

Stop a cluster

Start a cluster

Backup and restore