Greenplum Database Properties
This section describes each of the properties that you can define in a Greenplum Operator manifest file.
Synopsis
apiVersion: "greenplum.pivotal.io/v1"
kind: "GreenplumCluster"
metadata:
name: <string>
namespace: <string>
spec:
masterAndStandby:
standby: <yes|no>
hostBasedAuthentication: |
[ host <database> <role> <address> <authentication-method> ]
[ ... ]
memory: <memory-limit>
cpu: <cpu-limit>
storageClassName: <storage-class>
storageSize: <size>
workerSelector: {
<label>: "<value>"
[ ... ]
}
antiAffinity: <yes|no>
segments:
primarySegmentCount: <int>
memory: <memory-limit>
cpu: <cpu-limit>
storageClassName: <storage-class>
storageSize: <size>
workerSelector: {
<label>: "<value>"
[ ... ]
}
antiAffinity: <yes|no>
mirrors: <yes|no>
pxf:
serviceName: "<pxf-service-name>"
gptext:
serviceName: "<gptext-service-name>"
Description
You specify Greenplum cluster configuration properties to the Greenplum Operator via a YAML-formatted manifest file. A sample manifest file is provided in workspace/my-greenplum-cluster.yaml
. The current version of the manifest supports configuring the cluster name, number of segments, and the memory, cpu, and storage settings for master and segment pods. See also Deploying or Redeploying a Greenplum Cluster for information about deploying a new cluster using a manifest file.
Keywords and Values
Cluster Metadata
name: <string>
kubectl
commands using this name. For example, if you set the name to my-greenplum
then you can use commands like kubectl get all -l greenplum-cluster=my-greenplum
or kubectl get pvc -l greenplum-cluster=my-greenplum
to get all resources or PVCs associated with the Greenplum cluster instance, respectively. This value cannot be dynamically changed for an existing cluster. If you attempt to change this value and re-apply it to an existing cluster, the Operator will interpret the change as a new deployment and reject it as only one Greenplum cluster instance is allowed per namespace.
namespace: <string>
$ kubectl config set-context $(kubectl config current-context) --namespace=<NAMESPACE>
namespace
value.Segment Configuration
masterAndStandby:
, segments:
masterAndStandby:
settings apply only to both the master and standby master pods. All Greenplum for Kubernetes clusters include a standby master. The segments:
section applies to each primary segment and mirror segment pod. All Greenplum for Kubernetes clusters use segment mirroring.standby: <yes or no>
Note: You cannot change this value for an existing cluster unless you first delete both the deployed cluster and the PVCs that were created for that cluster. This will result in a new, empty Greenplum cluster. See Deleting Greenplum Persistent Volume Claims.
Note: If standby/mirrors is set to “no”, antiAffinity must also be set to “no”.
hostBasedAuthentication:
pg_hba.conf
file generated for the Greenplum cluster. Each entry (multiple entries are possible) must include the items host <database> <role> <address> <authentication-method>
in that order, to enable a role to access the indicated database (or all
databases) from the specified CIDR and authentication method. See Allowing Connections to Greenplum Database in the Greenplum Database documentation for more information about pg_hba.conf
file entries.This value cannot be dynamically changed for an existing cluster. The Operator only uses this value to populate the initial
pg_hba.conf
file that is created with a new cluster. You cannot use this property to change the existing generated file; instead, modify it directly on the master
pod using a text editor. See the section on Editing the pg_hba.conf File
in Allowing Connections to Greenplum Database.primarySegmentCount: <int>
segment-<type>-<number>
where the segment <type>
is either a
for primary segments or b
for mirror segments. Segment numbering starts at zero. If you omit this property, the Operator will fail to create a Greenplum cluster because it requires at least 1 primary/mirror segment pair.You can increase this value and re-apply it to an existing cluster, and the Greenplum operator automatically creates the new segment pods and initializes the Greenplum segment instances. You can optionally redistribute existing data to the new segments and/or delete the expansion schema that is created during this process. See Expanding a Greenplum Deployment.
Note: You cannot decrease this value for an existing cluster unless you first delete both the deployed cluster and the PVCs that were created for that cluster. This will result in a new, empty Greenplum cluster. See Deleting Greenplum Persistent Volume Claims.
memory: <memory-limit>
4.5Gi
.). If omitted or left empty, the pod has no upper bound on the memory resource it can use or inherits the default limit if one is specified in its deployed namespace. See Assign Memory Resources to Containers and Pods in the Kubernetes documentation for more information. This value cannot be dynamically changed for an existing cluster. If you attempt to make changes to this value and re-apply it to an existing cluster, the change will be rejected. If you wish to update this value, you must delete the existing cluster and recreate the cluster for the new value to take effect.
Note: If you do not want to specify a memory limit, comment-out or remove the
memory:
keyword from the YAML file, or specify an empty string for its value (memory: ""
). If the keyword appears in the YAML file, you must assign a valid string value to it.cpu: <cpu-limit>
cpu: "1.2"
). If omitted or left empty, the pod has no upper bound on the CPU resource it can use or inherits the default limit if one is specified in its deployed namespace. See Assign CPU Resources to Containers and Pods in the Kubernetes documentation for more information.This value cannot be dynamically changed for an existing cluster. If you attempt to make changes to this value and re-apply it to an existing cluster, the change will be rejected. If you wish to update this value, you must delete the existing cluster and recreate the cluster for the new value to take effect.
Note: If you do not want to specify a cpu limit, comment-out or remove the
cpu:
keyword from the YAML file, or specify an empty string for its value (cpu: ""
). If the keyword appears in the YAML file, you must assign a valid string value to it.storageClassName: <storage-class>
For best performance, Pivotal recommends using persistent volumes that are backed by a local SSD with the XFS filesystem, using
readahead
cache for best performance. Use the mount options rw,nodev,noatime,nobarrier,inode64
to mount the volume. See Creating Local Persistent Volumes for Greenplum for information about manually provisioning local persistent volumes. See Optimizing Persistent Disk and Local SSD Performance in the Google Cloud documentation for information about the performance characteristics of different storage types.You cannot change this value for an existing cluster unless you first delete both the deployed cluster and the PVCs that were created for that cluster. See Deleting Greenplum Persistent Volume Claims.
storageSize: <size>
100G
, 1T
).You cannot change this value for an existing cluster unless you first delete both the deployed cluster and the PVCs that were created for that cluster. This will result in a new, empty Greenplum cluster. See Deleting Greenplum Persistent Volume Claims.
workerSelector: <map of key-value pairs>
nodeSelector
attribute. You can define the workerSelector
attribute for Greenplum master and standby pods and/or for segment pods. If a workerSelector
is not desired, remove the workerSelector
attribute from the manifest file. For example, consider the case where you assign the label
gpdb-worker=master
to one or more pods using the command:
$ kubectl label node <node_name> gpdb-worker=master
Similarly, pods reserved for Greenplum segments might be assigned the gpdb-worker=segments
label:
$ kubectl label node <node_name> gpdb-worker=segments
With the above labels present in your cluster, you would edit the Greenplum Operator manifest file to specify the same key-value pairs in the workerSelector
attribute. This shows the relevant excerpt from the manifest file:
masterAndStandby:
storageClassName: gpdb-storage
storageSize: 5G
workerSelector: {
gpdb-worker: "master"
}
segments:
primarySegmentCount: 6
storageClassName: gpdb-storage
storageSize: 50G
workerSelector: {
gpdb-worker: "segments"
}
This value cannot be dynamically changed for an existing cluster. If you want to update this value, you must first delete the existing cluster and then recreate the cluster for the new value to take effect.
antiAffinity: <yes or no>
Notes:
- If you are using virtual machines, always ensure that there is one Kubernetes worker per server for to ensure high availability.
- Set
antiAffinity
to “yes” unless the deployment is to a single Kubernetes worker node. - The
antiAffinity
values formasterAndStandby
andsegments
must be the same. Otherwise, the cluster will fail to deploy.
This value cannot be dynamically changed for an existing cluster. If you wish to update this value, you must delete the existing cluster and recreate the cluster for the new value to take effect.
mirrors: <yes or no>
Note: You cannot change this value for an existing cluster unless you first delete both the deployed cluster and the PVCs that were created for that cluster. This will result in a new, empty Greenplum cluster. See Deleting Greenplum Persistent Volume Claims.
Note: If standby/mirrors is set to “no”, antiAffinity must also be set to “no”.
PXF Configuration
pxf.serviceName: "<pxf_service_name>"
GreenplumPXFService
configuration in your manifest file, specify its name here. As a best practice, keep the PXF service configuration properties in the same manifest file as Greenplum Database, as shown in the workspace/samples/my-gp-with-pxf-instance.yaml
file. This simplifies upgrades or changes to the related service objects. When pxf.serviceName
is set, the PXF extension is automatically created in the gpadmin
database.GPText Configuration
gptext.serviceName: "<gptext_service_name>"
GreenplumTextService
configuration in your manifest file, specify its name here. As a best practice, keep the GPText configuration properties in the same manifest file as Greenplum Database, as shown in the workspace/samples/my-gp-with-gptext-instance.yaml
file. This simplifies upgrades or changes to the related service objects. When gptext.serviceName
is set, the gptext-installsql
script is automatically run against the gpadmin
database.Examples
See the workspace/my-greenplum-cluster.yaml
for an example manifest.
See Also
Deploying or Redeploying a Greenplum Cluster, Deleting a Greenplum Cluster, Installing Greenplum for Kubernetes.