From 4adc1e0ec0d6f119ec8bf7dce2e64045cd5c68af Mon Sep 17 00:00:00 2001 From: Neaj Morshad Date: Thu, 7 Nov 2024 19:03:01 +0600 Subject: [PATCH] Finish standalone Signed-off-by: Neaj Morshad --- .../reconfigure/ms-standalone.yaml | 25 + .../msops-reconfigure-standalone-apply.yaml | 16 + .../msops-reconfigure-standalone.yaml | 14 + docs/guides/mongodb/reconfigure/overview.md | 2 +- docs/guides/mssqlserver/reconfigure/_index.md | 10 + .../mssqlserver/reconfigure/ag_cluster.md | 647 ++++++++++++++++++ .../mssqlserver/reconfigure/overview.md | 54 ++ .../mssqlserver/reconfigure/standalone.md | 526 ++++++++++++++ 8 files changed, 1293 insertions(+), 1 deletion(-) create mode 100644 docs/examples/mssqlserver/reconfigure/ms-standalone.yaml create mode 100644 docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml create mode 100644 docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml create mode 100644 docs/guides/mssqlserver/reconfigure/_index.md create mode 100644 docs/guides/mssqlserver/reconfigure/ag_cluster.md create mode 100644 docs/guides/mssqlserver/reconfigure/overview.md create mode 100644 docs/guides/mssqlserver/reconfigure/standalone.md diff --git a/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml b/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml new file mode 100644 index 0000000000..589bd189d1 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml @@ -0,0 +1,25 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-standalone + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml new file mode 100644 index 0000000000..0199028a1b --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml @@ -0,0 +1,16 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml new file mode 100644 index 0000000000..5c0f52531a --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml @@ -0,0 +1,14 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/guides/mongodb/reconfigure/overview.md b/docs/guides/mongodb/reconfigure/overview.md index 4975e7588a..50683c37a9 100644 --- a/docs/guides/mongodb/reconfigure/overview.md +++ b/docs/guides/mongodb/reconfigure/overview.md @@ -45,7 +45,7 @@ The Reconfiguring MongoDB process consists of the following steps: 6. When it finds a `MongoDBOpsRequest` CR, it halts the `MongoDB` object which is referred from the `MongoDBOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MongoDB` object during the reconfiguring process. -7. Then the `KubeDB` Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the `MogoDBOpsRequest` CR. +7. Then the `KubeDB` Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the `MongoDBOpsRequest` CR. 8. Then the `KubeDB` Ops-manager operator will restart the related PetSet Pods so that they restart with the new configuration defined in the `MongoDBOpsRequest` CR. diff --git a/docs/guides/mssqlserver/reconfigure/_index.md b/docs/guides/mssqlserver/reconfigure/_index.md new file mode 100644 index 0000000000..3fa45903ac --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/_index.md @@ -0,0 +1,10 @@ +--- +title: Reconfigure +menu: + docs_{{ .version }}: + identifier: ms-reconfigure + name: Reconfigure + parent: guides-mssqlserver + weight: 67 +menu_name: docs_{{ .version }} +--- \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure/ag_cluster.md b/docs/guides/mssqlserver/reconfigure/ag_cluster.md new file mode 100644 index 0000000000..82c58f1932 --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/ag_cluster.md @@ -0,0 +1,647 @@ +--- +title: Reconfigure MSSQLServer Replicaset +menu: + docs_{{ .version }}: + identifier: mg-reconfigure-replicaset + name: Replicaset + parent: mg-reconfigure + weight: 30 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfigure MSSQLServer Replicaset Database + +This guide will show you how to use `KubeDB` Ops-manager operator to reconfigure a MSSQLServer Replicaset. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [ReplicaSet](/docs/guides/mssqlserver/clustering/replicaset.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Reconfigure Overview](/docs/guides/mssqlserver/reconfigure/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. + +Now, we are going to deploy a `MSSQLServer` Replicaset using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to reconfigure its configuration. + +### Prepare MSSQLServer Replicaset + +Now, we are going to deploy a `MSSQLServer` Replicaset database with version `4.4.26`. + +### Deploy MSSQLServer + +At first, we will create `mongod.conf` file containing required configuration settings. + +```ini +$ cat mongod.conf +net: + maxIncomingConnections: 10000 +``` +Here, `maxIncomingConnections` is set to `10000`, whereas the default value is `65536`. + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo mg-custom-config --from-file=./mongod.conf +secret/mg-custom-config created +``` + +In this section, we are going to create a MSSQLServer object specifying `spec.configSecret` field to apply this custom configuration. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1 +kind: MSSQLServer +metadata: + name: mg-replicaset + namespace: demo +spec: + version: "4.4.26" + replicas: 3 + replicaSet: + name: rs0 + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + configSecret: + name: mg-custom-config +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/mg-replicaset-config.yaml +MSSQLServer.kubedb.com/mg-replicaset created +``` + +Now, wait until `mg-replicaset` has status `Ready`. i.e, + +```bash +$ kubectl get mg -n demo +NAME VERSION STATUS AGE +mg-replicaset 4.4.26 Ready 19m +``` + +Now, we will check if the database has started with the custom configuration we have provided. + +First we need to get the username and password to connect to a MSSQLServer instance, +```bash +$ kubectl get secrets -n demo mg-replicaset-auth -o jsonpath='{.data.\username}' | base64 -d +root + +$ kubectl get secrets -n demo mg-replicaset-auth -o jsonpath='{.data.\password}' | base64 -d +nrKuxni0wDSMrgwy +``` + +Now let's connect to a MSSQLServer instance and run a MSSQLServer internal command to check the configuration we have provided. + +```bash +$ kubectl exec -n demo mg-replicaset-0 -- mongo admin -u root -p nrKuxni0wDSMrgwy --eval "db._adminCommand( {getCmdLineOpts: 1})" --quiet +{ + "argv" : [ + "mongod", + "--dbpath=/data/db", + "--auth", + "--ipv6", + "--bind_ip_all", + "--port=27017", + "--tlsMode=disabled", + "--replSet=rs0", + "--keyFile=/data/configdb/key.txt", + "--clusterAuthMode=keyFile", + "--config=/data/configdb/mongod.conf" + ], + "parsed" : { + "config" : "/data/configdb/mongod.conf", + "net" : { + "bindIp" : "*", + "ipv6" : true, + "maxIncomingConnections" : 10000, + "port" : 27017, + "tls" : { + "mode" : "disabled" + } + }, + "replication" : { + "replSet" : "rs0" + }, + "security" : { + "authorization" : "enabled", + "clusterAuthMode" : "keyFile", + "keyFile" : "/data/configdb/key.txt" + }, + "storage" : { + "dbPath" : "/data/db" + } + }, + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1614668500, 1), + "signature" : { + "hash" : BinData(0,"7sh886HhsNYajGxYGp5Jxi52IzA="), + "keyId" : NumberLong("6934943333319966722") + } + }, + "operationTime" : Timestamp(1614668500, 1) +} +``` + +As we can see from the configuration of ready MSSQLServer, the value of `maxIncomingConnections` has been set to `10000`. + +### Reconfigure using new config secret + +Now we will reconfigure this database to set `maxIncomingConnections` to `20000`. + +Now, we will edit the `mongod.conf` file containing required configuration settings. + +```ini +$ cat mongod.conf +net: + maxIncomingConnections: 20000 +``` + +Then, we will create a new secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo new-custom-config --from-file=./mongod.conf +secret/new-custom-config created +``` + +#### Create MSSQLServerOpsRequest + +Now, we will use this secret to replace the previous secret using a `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-reconfigure-replicaset + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mg-replicaset + configuration: + replicaSet: + configSecret: + name: new-custom-config + readinessCriteria: + oplogMaxLagSeconds: 20 + objectsCountDiffPercentage: 10 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-replicaset` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.customConfig.replicaSet.configSecret.name` specifies the name of the new secret. +- `spec.customConfig.arbiter.configSecret.name` could also be specified with a config-secret. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#specreadinesscriteria) on the respective sections to understand the `readinessCriteria`, `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/mops-reconfigure-replicaset.yaml +MSSQLServeropsrequest.ops.kubedb.com/mops-reconfigure-replicaset created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will update the `configSecret` of `MSSQLServer` object. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +Every 2.0s: kubectl get MSSQLServeropsrequest -n demo +NAME TYPE STATUS AGE +mops-reconfigure-replicaset Reconfigure Successful 113s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo mops-reconfigure-replicaset +Name: mops-reconfigure-replicaset +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-02T07:04:31Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:apply: + f:configuration: + .: + f:replicaSet: + .: + f:configSecret: + .: + f:name: + f:databaseRef: + .: + f:name: + f:readinessCriteria: + .: + f:objectsCountDiffPercentage: + f:oplogMaxLagSeconds: + f:timeout: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-02T07:04:31Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:spec: + f:configuration: + f:replicaSet: + f:podTemplate: + .: + f:controller: + f:metadata: + f:spec: + .: + f:resources: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-02T07:04:31Z + Resource Version: 29869 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-reconfigure-replicaset + UID: 064733d6-19db-4153-82f7-bc0580116ee6 +Spec: + Apply: IfReady + Configuration: + Replica Set: + Config Secret: + Name: new-custom-config + Database Ref: + Name: mg-replicaset + Readiness Criteria: + Objects Count Diff Percentage: 10 + Oplog Max Lag Seconds: 20 + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2021-03-02T07:04:31Z + Message: MSSQLServer ops request is reconfiguring database + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2021-03-02T07:06:21Z + Message: Successfully Reconfigured MSSQLServer + Observed Generation: 1 + Reason: ReconfigureReplicaset + Status: True + Type: ReconfigureReplicaset + Last Transition Time: 2021-03-02T07:06:21Z + Message: Successfully completed the modification process. + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal PauseDatabase 2m55s KubeDB Ops-manager operator Pausing MSSQLServer demo/mg-replicaset + Normal PauseDatabase 2m55s KubeDB Ops-manager operator Successfully paused MSSQLServer demo/mg-replicaset + Normal ReconfigureReplicaset 65s KubeDB Ops-manager operator Successfully Reconfigured MSSQLServer + Normal ResumeDatabase 65s KubeDB Ops-manager operator Resuming MSSQLServer demo/mg-replicaset + Normal ResumeDatabase 65s KubeDB Ops-manager operator Successfully resumed MSSQLServer demo/mg-replicaset + Normal Successful 65s KubeDB Ops-manager operator Successfully Reconfigured Database +``` + +Now let's connect to a MSSQLServer instance and run a MSSQLServer internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -n demo mg-replicaset-0 -- mongo admin -u root -p nrKuxni0wDSMrgwy --eval "db._adminCommand( {getCmdLineOpts: 1})" --quiet +{ + "argv" : [ + "mongod", + "--dbpath=/data/db", + "--auth", + "--ipv6", + "--bind_ip_all", + "--port=27017", + "--tlsMode=disabled", + "--replSet=rs0", + "--keyFile=/data/configdb/key.txt", + "--clusterAuthMode=keyFile", + "--config=/data/configdb/mongod.conf" + ], + "parsed" : { + "config" : "/data/configdb/mongod.conf", + "net" : { + "bindIp" : "*", + "ipv6" : true, + "maxIncomingConnections" : 20000, + "port" : 27017, + "tls" : { + "mode" : "disabled" + } + }, + "replication" : { + "replSet" : "rs0" + }, + "security" : { + "authorization" : "enabled", + "clusterAuthMode" : "keyFile", + "keyFile" : "/data/configdb/key.txt" + }, + "storage" : { + "dbPath" : "/data/db" + } + }, + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1614668887, 1), + "signature" : { + "hash" : BinData(0,"5q35Y51+YpbVHFKoaU7lUWi38oY="), + "keyId" : NumberLong("6934943333319966722") + } + }, + "operationTime" : Timestamp(1614668887, 1) +} +``` + +As we can see from the configuration of ready MSSQLServer, the value of `maxIncomingConnections` has been changed from `10000` to `20000`. So the reconfiguration of the database is successful. + + +### Reconfigure using apply config + +Now we will reconfigure this database again to set `maxIncomingConnections` to `30000`. This time we won't use a new secret. We will use the `applyConfig` field of the `MSSQLServerOpsRequest`. This will merge the new config in the existing secret. + +#### Create MSSQLServerOpsRequest + +Now, we will use the new configuration in the `applyConfig` field in the `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-reconfigure-apply-replicaset + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mg-replicaset + configuration: + replicaSet: + applyConfig: + mongod.conf: |- + net: + maxIncomingConnections: 30000 + readinessCriteria: + oplogMaxLagSeconds: 20 + objectsCountDiffPercentage: 10 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `mops-reconfigure-apply-replicaset` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.configuration.replicaSet.applyConfig` specifies the new configuration that will be merged in the existing secret. +- `spec.customConfig.arbiter.configSecret.name` could also be specified with a config-secret. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#specreadinesscriteria) on the respective sections to understand the `readinessCriteria`, `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/mops-reconfigure-apply-replicaset.yaml +MSSQLServeropsrequest.ops.kubedb.com/mops-reconfigure-apply-replicaset created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will merge this new config with the existing configuration. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +Every 2.0s: kubectl get MSSQLServeropsrequest -n demo +NAME TYPE STATUS AGE +mops-reconfigure-apply-replicaset Reconfigure Successful 109s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo mops-reconfigure-apply-replicaset +Name: mops-reconfigure-apply-replicaset +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-02T07:09:39Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:apply: + f:configuration: + .: + f:replicaSet: + .: + f:applyConfig: + f:databaseRef: + .: + f:name: + f:readinessCriteria: + .: + f:objectsCountDiffPercentage: + f:oplogMaxLagSeconds: + f:timeout: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-02T07:09:39Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:spec: + f:configuration: + f:replicaSet: + f:podTemplate: + .: + f:controller: + f:metadata: + f:spec: + .: + f:resources: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-02T07:09:39Z + Resource Version: 31005 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-reconfigure-apply-replicaset + UID: 0137442b-1b04-43ed-8de7-ecd913b44065 +Spec: + Apply: IfReady + Configuration: + Replica Set: + Apply Config: net: + maxIncomingConnections: 30000 + + Database Ref: + Name: mg-replicaset + Readiness Criteria: + Objects Count Diff Percentage: 10 + Oplog Max Lag Seconds: 20 + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2021-03-02T07:09:39Z + Message: MSSQLServer ops request is reconfiguring database + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2021-03-02T07:11:14Z + Message: Successfully Reconfigured MSSQLServer + Observed Generation: 1 + Reason: ReconfigureReplicaset + Status: True + Type: ReconfigureReplicaset + Last Transition Time: 2021-03-02T07:11:14Z + Message: Successfully completed the modification process. + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal PauseDatabase 9m20s KubeDB Ops-manager operator Pausing MSSQLServer demo/mg-replicaset + Normal PauseDatabase 9m20s KubeDB Ops-manager operator Successfully paused MSSQLServer demo/mg-replicaset + Normal ReconfigureReplicaset 7m45s KubeDB Ops-manager operator Successfully Reconfigured MSSQLServer + Normal ResumeDatabase 7m45s KubeDB Ops-manager operator Resuming MSSQLServer demo/mg-replicaset + Normal ResumeDatabase 7m45s KubeDB Ops-manager operator Successfully resumed MSSQLServer demo/mg-replicaset + Normal Successful 7m45s KubeDB Ops-manager operator Successfully Reconfigured Database +``` + +Now let's connect to a MSSQLServer instance and run a MSSQLServer internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -n demo mg-replicaset-0 -- mongo admin -u root -p nrKuxni0wDSMrgwy --eval "db._adminCommand( {getCmdLineOpts: 1})" --quiet +{ + "argv" : [ + "mongod", + "--dbpath=/data/db", + "--auth", + "--ipv6", + "--bind_ip_all", + "--port=27017", + "--tlsMode=disabled", + "--replSet=rs0", + "--keyFile=/data/configdb/key.txt", + "--clusterAuthMode=keyFile", + "--config=/data/configdb/mongod.conf" + ], + "parsed" : { + "config" : "/data/configdb/mongod.conf", + "net" : { + "bindIp" : "*", + "ipv6" : true, + "maxIncomingConnections" : 30000, + "port" : 27017, + "tls" : { + "mode" : "disabled" + } + }, + "replication" : { + "replSet" : "rs0" + }, + "security" : { + "authorization" : "enabled", + "clusterAuthMode" : "keyFile", + "keyFile" : "/data/configdb/key.txt" + }, + "storage" : { + "dbPath" : "/data/db" + } + }, + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1614669580, 1), + "signature" : { + "hash" : BinData(0,"u/xTAa4aW/8bsRvBYPffwQCeTF0="), + "keyId" : NumberLong("6934943333319966722") + } + }, + "operationTime" : Timestamp(1614669580, 1) +} +``` + +As we can see from the configuration of ready MSSQLServer, the value of `maxIncomingConnections` has been changed from `20000` to `30000`. So the reconfiguration of the database using the `applyConfig` field is successful. + + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mg -n demo mg-replicaset +kubectl delete MSSQLServeropsrequest -n demo mops-reconfigure-replicaset mops-reconfigure-apply-replicaset +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure/overview.md b/docs/guides/mssqlserver/reconfigure/overview.md new file mode 100644 index 0000000000..e92f181ceb --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/overview.md @@ -0,0 +1,54 @@ +--- +title: Reconfiguring MSSQLServer +menu: + docs_{{ .version }}: + identifier: mg-reconfigure-overview + name: Overview + parent: mg-reconfigure + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfiguring SQL Server + +This guide will give an overview on how KubeDB Ops-manager operator reconfigures `MSSQLServer` database. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + +## How Reconfiguring MSSQLServer Process Works + +The following diagram shows how KubeDB Ops-manager operator reconfigures `MSSQLServer` database. Open the image in a new tab to see the enlarged version. + +
+  Reconfiguring process of MSSQLServer +
Fig: Reconfiguring process of MSSQLServer
+
+ +The Reconfiguring MSSQLServer process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource (CR). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CR. + +3. When the operator finds a `MSSQLServer` CR, it creates required number of `PetSets` and related necessary stuff like secrets, services, etc. + +4. Then, in order to reconfigure the `MSSQLServer` database the user creates a `MSSQLServerOpsRequest` CR with desired information. + +5. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +6. When it finds a `MSSQLServerOpsRequest` CR, it halts the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the reconfiguring process. + +7. Then the `KubeDB` Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the `MSSQLServerOpsRequest` CR. + +8. Then the `KubeDB` Ops-manager operator will restart the related PetSet Pods so that they restart with the new configuration defined in the `MSSQLServerOpsRequest` CR. + +9. After the successful reconfiguring of the `MSSQLServer`, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator resumes its usual operations. + +In the next docs, we are going to show a step-by-step guide on reconfiguring MSSQLServer database using `MSSQLServerOpsRequest` CR. \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure/standalone.md b/docs/guides/mssqlserver/reconfigure/standalone.md new file mode 100644 index 0000000000..72dc0440ec --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/standalone.md @@ -0,0 +1,526 @@ +--- +title: Reconfigure Standalone MSSQLServer Database +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-standalone + name: Standalone + parent: ms-reconfigure + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfigure MSSQLServer Standalone Database + +This guide will show you how to use `KubeDB` Ops-manager operator to reconfigure a MSSQLServer standalone database. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Reconfigure Overview](/docs/guides/mssqlserver/reconfigure/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/reconfigure) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. + +Now, we are going to deploy a `MSSQLServer` standalone using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to reconfigure its configuration. + +### Prepare MSSQLServer Standalone Database + +Now, we are going to deploy a `MSSQLServer` standalone database with version `2022-cu12`. + +### Deploy MSSQLServer standalone + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +Now, we will create `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2048 +``` +Here, `memorylimitmb` is set to `2048`, whereas the default value is `12280`. + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo ms-custom-config --from-file=./mssql.conf +secret/ms-custom-config created +``` + +In this section, we are going to create a MSSQLServer object specifying `spec.configSecret` field to apply this custom configuration. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-standalone + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml +MSSQLServer.kubedb.com/ms-standalone created +``` + +Now, wait until `ms-standalone` has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +ms-standalone 4.4.26 Ready 23s +``` + +Now, we will check if the database has started with the custom configuration we have provided. + +First we need to get the username and password to connect to a MSSQLServer instance, +```bash +$ kubectl get secrets -n demo ms-standalone-auth -o jsonpath='{.data.\username}' | base64 -d +sa + +$ kubectl get secrets -n demo ms-standalone-auth -o jsonpath='{.data.\password}' | base64 -d +SERtEyH1RMMEsvE0 +``` + +Now let's connect to the SQL Server instance and run internal command to check the configuration we have provided. + +```bash +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 2048 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SERtEyH1RMMEsvE0 +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 2048 + +(1 rows affected) +1> +``` + +As we can see from the configuration of running MSSQLServer, the value of `physical_memory_mb` has been set to `2048`. + +### Reconfigure using new secret + +Now we will reconfigure this database to set `memorylimitmb` to `2560`. + +Now, we will edit the `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2560 +``` + +Then, we will create a new secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo new-custom-config --from-file=./mssql.conf +secret/new-custom-config created +``` + +#### Create MSSQLServerOpsRequest + +Now, we will use this secret to replace the previous secret using a `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `ms-standalone` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.configuration.configSecret.name` specifies the name of the new secret. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/mops-reconfigure-standalone.yaml +MSSQLServeropsrequest.ops.kubedb.com/mops-reconfigure-standalone created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will update the `configSecret` of `MSSQLServer` object. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +Every 2.0s: kubectl get MSSQLServeropsrequest -n demo + +NAME TYPE STATUS AGE +msops-reconfigure-standalone Reconfigure Successful 2m42s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo mops-reconfigure-standalone +Name: msops-reconfigure-standalone +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-07T12:46:35Z + Generation: 1 + Resource Version: 160710 + UID: a3859b47-575c-40a5-84d4-38fb9f37a8ef +Spec: + Apply: IfReady + Configuration: + Config Secret: + Name: new-custom-config + Database Ref: + Name: ms-standalone + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2024-11-07T12:46:35Z + Message: MSSQLServer ops-request has started to reconfigure MSSQLServer nodes + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2024-11-07T12:46:49Z + Message: successfully reconciled the mssqlserver with new configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-07T12:46:54Z + Message: get pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:46:54Z + Message: evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:47:34Z + Message: check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--ms-standalone-0 + Last Transition Time: 2024-11-07T12:47:39Z + Message: Successfully Restarted Pods after reconfiguration + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-07T12:47:39Z + Message: Successfully completed reconfiguring for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 3m45s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-reconfigure-standalone + Normal Starting 3m45s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/ms-standalone + Normal Successful 3m45s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone + Normal UpdatePetSets 3m31s KubeDB Ops-manager Operator successfully reconciled the mssqlserver with new configuration + Warning get pod; ConditionStatus:True; PodName:ms-standalone-0 3m26s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:ms-standalone-0 3m26s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:ms-standalone-0 3m21s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:ms-standalone-0 2m46s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Normal RestartPods 2m41s KubeDB Ops-manager Operator Successfully Restarted Pods after reconfiguration + Normal Starting 2m41s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/ms-standalone + Normal Successful 2m41s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone +``` + +Now let's connect to SQL Server instance and run a internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 2560 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SERtEyH1RMMEsvE0 +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 2560 + +(1 rows affected) +1> +``` + +As we can see from the configuration of running SQL Server, the value of `physical_memory_mb` has been changed from `2048` to `2560`. So the reconfiguration of the database is successful. + + +### Reconfigure using apply config + +Now we will reconfigure this database again to set `memorylimitmb` to `3072`. This time we won't use a new secret. We will use the `applyConfig` field of the `MSSQLServerOpsRequest`. This will merge the new config in the existing secret. + +#### Create MSSQLServerOpsRequest + +Now, we will use the new configuration in the `applyConfig` field in the `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `ms-standalone` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.configuration.applyConfig` specifies the new configuration that will be merged in the existing secret. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml +MSSQLServeropsrequest.ops.kubedb.com/msops-reconfigure-standalone-apply created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will merge this new config with the existing configuration. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +Every 2.0s: kubectl get MSSQLServeropsrequest -n demo + +NAME TYPE STATUS AGE +msops-reconfigure-standalone-apply Reconfigure Successful 2m2s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo msops-reconfigure-standalone-apply +Name: msops-reconfigure-standalone-apply +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-07T12:57:43Z + Generation: 1 + Resource Version: 161738 + UID: e9da170c-5d6b-41fd-ae05-b39c6c5f3029 +Spec: + Apply: IfReady + Configuration: + Apply Config: + mssql.conf: [memory] +memorylimitmb = 3072 + Database Ref: + Name: ms-standalone + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2024-11-07T12:57:43Z + Message: MSSQLServer ops-request has started to reconfigure MSSQLServer nodes + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2024-11-07T12:57:46Z + Message: Successfully prepared user provided custom config secret + Observed Generation: 1 + Reason: PrepareCustomConfig + Status: True + Type: PrepareCustomConfig + Last Transition Time: 2024-11-07T12:57:51Z + Message: successfully reconciled the mssqlserver with new configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-07T12:57:56Z + Message: get pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:57:56Z + Message: evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:58:31Z + Message: check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--ms-standalone-0 + Last Transition Time: 2024-11-07T12:58:36Z + Message: Successfully Restarted Pods after reconfiguration + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-07T12:58:36Z + Message: Successfully completed reconfiguring for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 2m40s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-reconfigure-standalone-apply + Normal Starting 2m40s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/ms-standalone + Normal Successful 2m40s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone-apply + Normal UpdatePetSets 2m32s KubeDB Ops-manager Operator successfully reconciled the mssqlserver with new configuration + Warning get pod; ConditionStatus:True; PodName:ms-standalone-0 2m27s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:ms-standalone-0 2m27s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:ms-standalone-0 2m22s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:ms-standalone-0 112s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Normal RestartPods 107s KubeDB Ops-manager Operator Successfully Restarted Pods after reconfiguration + Normal Starting 107s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/ms-standalone + Normal Successful 107s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone-apply +``` + +Now let's connect to the SQL Server instance and run a internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 3072 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SERtEyH1RMMEsvE0 +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 3072 + +(1 rows affected) +1> +``` + +As we can see from the configuration of running SQL Server, the value of `physical_memory_mb` has been changed from `2560` to `3072`. So the reconfiguration of the database using the `applyConfig` field is successful. + + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo ms-standalone +kubectl delete MSSQLServeropsrequest -n demo mops-reconfigure-standalone msops-reconfigure-standalone-apply +``` \ No newline at end of file