diff --git a/.github/workflows/sync-and-process-files.yml b/.github/workflows/sync-and-process-files.yml
index 795e72e9212..2dd1bcb0918 100644
--- a/.github/workflows/sync-and-process-files.yml
+++ b/.github/workflows/sync-and-process-files.yml
@@ -37,6 +37,9 @@ jobs:
with:
node-version: '14'
+ - name: update npm
+ run: npm install -g npm@7
+
- name: Process changes
run: |
case ${{ github.event.client_payload.repo }} in
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/api_reference.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/api_reference.mdx
index 7176b8dec3d..a14b608179c 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/api_reference.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/api_reference.mdx
@@ -21,46 +21,45 @@ Below you will find a description of the defined resources:
-- [AffinityConfiguration](#AffinityConfiguration)
-- [AzureCredentials](#AzureCredentials)
-- [Backup](#Backup)
-- [BackupConfiguration](#BackupConfiguration)
-- [BackupList](#BackupList)
-- [BackupSpec](#BackupSpec)
-- [BackupStatus](#BackupStatus)
-- [BarmanObjectStoreConfiguration](#BarmanObjectStoreConfiguration)
-- [BootstrapConfiguration](#BootstrapConfiguration)
-- [BootstrapInitDB](#BootstrapInitDB)
-- [BootstrapPgBaseBackup](#BootstrapPgBaseBackup)
-- [BootstrapRecovery](#BootstrapRecovery)
-- [CertificatesConfiguration](#CertificatesConfiguration)
-- [CertificatesStatus](#CertificatesStatus)
-- [Cluster](#Cluster)
-- [ClusterList](#ClusterList)
-- [ClusterSpec](#ClusterSpec)
-- [ClusterStatus](#ClusterStatus)
-- [ConfigMapKeySelector](#ConfigMapKeySelector)
-- [ConfigMapResourceVersion](#ConfigMapResourceVersion)
-- [DataBackupConfiguration](#DataBackupConfiguration)
-- [EPASConfiguration](#EPASConfiguration)
-- [ExternalCluster](#ExternalCluster)
-- [LocalObjectReference](#LocalObjectReference)
-- [MonitoringConfiguration](#MonitoringConfiguration)
-- [NodeMaintenanceWindow](#NodeMaintenanceWindow)
-- [PostgresConfiguration](#PostgresConfiguration)
-- [RecoveryTarget](#RecoveryTarget)
-- [ReplicaClusterConfiguration](#ReplicaClusterConfiguration)
-- [RollingUpdateStatus](#RollingUpdateStatus)
-- [S3Credentials](#S3Credentials)
-- [ScheduledBackup](#ScheduledBackup)
-- [ScheduledBackupList](#ScheduledBackupList)
-- [ScheduledBackupSpec](#ScheduledBackupSpec)
-- [ScheduledBackupStatus](#ScheduledBackupStatus)
-- [SecretKeySelector](#SecretKeySelector)
-- [SecretsResourceVersion](#SecretsResourceVersion)
-- [StorageConfiguration](#StorageConfiguration)
-- [WalBackupConfiguration](#WalBackupConfiguration)
-
+- [AffinityConfiguration](#AffinityConfiguration)
+- [AzureCredentials](#AzureCredentials)
+- [Backup](#Backup)
+- [BackupConfiguration](#BackupConfiguration)
+- [BackupList](#BackupList)
+- [BackupSpec](#BackupSpec)
+- [BackupStatus](#BackupStatus)
+- [BarmanObjectStoreConfiguration](#BarmanObjectStoreConfiguration)
+- [BootstrapConfiguration](#BootstrapConfiguration)
+- [BootstrapInitDB](#BootstrapInitDB)
+- [BootstrapPgBaseBackup](#BootstrapPgBaseBackup)
+- [BootstrapRecovery](#BootstrapRecovery)
+- [CertificatesConfiguration](#CertificatesConfiguration)
+- [CertificatesStatus](#CertificatesStatus)
+- [Cluster](#Cluster)
+- [ClusterList](#ClusterList)
+- [ClusterSpec](#ClusterSpec)
+- [ClusterStatus](#ClusterStatus)
+- [ConfigMapKeySelector](#ConfigMapKeySelector)
+- [ConfigMapResourceVersion](#ConfigMapResourceVersion)
+- [DataBackupConfiguration](#DataBackupConfiguration)
+- [EPASConfiguration](#EPASConfiguration)
+- [ExternalCluster](#ExternalCluster)
+- [LocalObjectReference](#LocalObjectReference)
+- [MonitoringConfiguration](#MonitoringConfiguration)
+- [NodeMaintenanceWindow](#NodeMaintenanceWindow)
+- [PostgresConfiguration](#PostgresConfiguration)
+- [RecoveryTarget](#RecoveryTarget)
+- [ReplicaClusterConfiguration](#ReplicaClusterConfiguration)
+- [RollingUpdateStatus](#RollingUpdateStatus)
+- [S3Credentials](#S3Credentials)
+- [ScheduledBackup](#ScheduledBackup)
+- [ScheduledBackupList](#ScheduledBackupList)
+- [ScheduledBackupSpec](#ScheduledBackupSpec)
+- [ScheduledBackupStatus](#ScheduledBackupStatus)
+- [SecretKeySelector](#SecretKeySelector)
+- [SecretsResourceVersion](#SecretsResourceVersion)
+- [StorageConfiguration](#StorageConfiguration)
+- [WalBackupConfiguration](#WalBackupConfiguration)
| string |
+| `additionalPodAntiAffinity` | AdditionalPodAntiAffinity allows to specify pod anti-affinity terms to be added to the ones generated by the operator if EnablePodAntiAffinity is set to true (default) or to be used exclusively if set to false. | \*corev1.PodAntiAffinity |
+| `additionalPodAffinity ` | AdditionalPodAffinity allows to specify pod affinity terms to be passed to all the cluster's pods. | \*corev1.PodAffinity |
| [BackupSpec](#BackupSpec) |
+| `status ` | Most recently observed status of the backup. This data may not be up to date. Populated by the system. Read-only. More info: | [BackupStatus](#BackupStatus) |
| [metav1.ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta) |
+| `items ` | List of backups - *mandatory* | [\[\]Backup](#Backup) |
| [\*RecoveryTarget](#RecoveryTarget) |
| [ClusterSpec](#ClusterSpec) |
+| `status ` | Most recently observed status of the cluster. This data may not be up to date. Populated by the system. Read-only. More info: | [ClusterStatus](#ClusterStatus) |
| [metav1.ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta) |
+| `items ` | List of clusters - *mandatory* | [\[\]Cluster](#Cluster) |
:`) and digests for deterministic and repeatable deployments (`:@sha256:`) | string
-`imagePullPolicy ` | Image pull policy. One of `Always`, `Never` or `IfNotPresent`. If not defined, it defaults to `IfNotPresent`. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images | corev1.PullPolicy
-`postgresUID ` | The UID of the `postgres` user inside the image, defaults to `26` | int64
-`postgresGID ` | The GID of the `postgres` user inside the image, defaults to `26` | int64
-`instances ` | Number of instances required in the cluster - *mandatory* | int32
-`minSyncReplicas ` | Minimum number of instances required in synchronous replication with the primary. Undefined or 0 allow writes to complete when no standby is available. | int32
-`maxSyncReplicas ` | The target value for the synchronous replication quorum, that can be decreased if the number of ready standbys is lower than this. Undefined or 0 disable synchronous replication. | int32
-`postgresql ` | Configuration of the PostgreSQL server | [PostgresConfiguration](#PostgresConfiguration)
-`bootstrap ` | Instructions to bootstrap this cluster | [*BootstrapConfiguration](#BootstrapConfiguration)
-`replica ` | Replica cluster configuration | [*ReplicaClusterConfiguration](#ReplicaClusterConfiguration)
-`superuserSecret ` | The secret containing the superuser password. If not defined a new secret will be created with a randomly generated password | [*LocalObjectReference](#LocalObjectReference)
-`enableSuperuserAccess` | When this option is enabled, the operator will use the `SuperuserSecret` to update the `postgres` user password (if the secret is not present, the operator will automatically create one). When this option is disabled, the operator will ignore the `SuperuserSecret` content, delete it when automatically created, and then blank the password of the `postgres` user by setting it to `NULL`. Enabled by default. | *bool
-`certificates ` | The configuration for the CA and related certificates | [*CertificatesConfiguration](#CertificatesConfiguration)
-`imagePullSecrets ` | The list of pull secrets to be used to pull the images. If the license key contains a pull secret that secret will be automatically included. | [[]LocalObjectReference](#LocalObjectReference)
-`storage ` | Configuration of the storage of the instances | [StorageConfiguration](#StorageConfiguration)
-`startDelay ` | The time in seconds that is allowed for a PostgreSQL instance to successfully start up (default 30) | int32
-`stopDelay ` | The time in seconds that is allowed for a PostgreSQL instance node to gracefully shutdown (default 30) | int32
-`affinity ` | Affinity/Anti-affinity rules for Pods | [AffinityConfiguration](#AffinityConfiguration)
-`resources ` | Resources requirements of every generated Pod. Please refer to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ for more information. | [corev1.ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#resourcerequirements-v1-core)
-`primaryUpdateStrategy` | Strategy to follow to upgrade the primary server during a rolling update procedure, after all replicas have been successfully updated: it can be automated (`unsupervised` - default) or manual (`supervised`) | PrimaryUpdateStrategy
-`backup ` | The configuration to be used for backups | [*BackupConfiguration](#BackupConfiguration)
-`nodeMaintenanceWindow` | Define a maintenance window for the Kubernetes nodes | [*NodeMaintenanceWindow](#NodeMaintenanceWindow)
-`licenseKey ` | The license key of the cluster. When empty, the cluster operates in trial mode and after the expiry date (default 30 days) the operator will cease any reconciliation attempt. For details, please refer to the license agreement that comes with the operator. | string
-`licenseKeySecret ` | The reference to the license key. When this is set it take precedence over LicenseKey. | [*corev1.SecretKeySelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#secretkeyselector-v1-core)
-`monitoring ` | The configuration of the monitoring infrastructure of this cluster | [*MonitoringConfiguration](#MonitoringConfiguration)
-`externalClusters ` | The list of external clusters which are used in the configuration | [[]ExternalCluster](#ExternalCluster)
-`logLevel ` | The instances' log level, one of the following values: error, info (default), debug, trace | string
+| Name | Description | Type |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| `description ` | Description of this PostgreSQL cluster | string |
+| `imageName ` | Name of the container image, supporting both tags (`:`) and digests for deterministic and repeatable deployments (`:@sha256:`) | string |
+| `imagePullPolicy ` | Image pull policy. One of `Always`, `Never` or `IfNotPresent`. If not defined, it defaults to `IfNotPresent`. Cannot be updated. More info: | corev1.PullPolicy |
+| `postgresUID ` | The UID of the `postgres` user inside the image, defaults to `26` | int64 |
+| `postgresGID ` | The GID of the `postgres` user inside the image, defaults to `26` | int64 |
+| `instances ` | Number of instances required in the cluster - *mandatory* | int32 |
+| `minSyncReplicas ` | Minimum number of instances required in synchronous replication with the primary. Undefined or 0 allow writes to complete when no standby is available. | int32 |
+| `maxSyncReplicas ` | The target value for the synchronous replication quorum, that can be decreased if the number of ready standbys is lower than this. Undefined or 0 disable synchronous replication. | int32 |
+| `postgresql ` | Configuration of the PostgreSQL server | [PostgresConfiguration](#PostgresConfiguration) |
+| `bootstrap ` | Instructions to bootstrap this cluster | [\*BootstrapConfiguration](#BootstrapConfiguration) |
+| `replica ` | Replica cluster configuration | [\*ReplicaClusterConfiguration](#ReplicaClusterConfiguration) |
+| `superuserSecret ` | The secret containing the superuser password. If not defined a new secret will be created with a randomly generated password | [\*LocalObjectReference](#LocalObjectReference) |
+| `enableSuperuserAccess` | When this option is enabled, the operator will use the `SuperuserSecret` to update the `postgres` user password (if the secret is not present, the operator will automatically create one). When this option is disabled, the operator will ignore the `SuperuserSecret` content, delete it when automatically created, and then blank the password of the `postgres` user by setting it to `NULL`. Enabled by default. | \*bool |
+| `certificates ` | The configuration for the CA and related certificates | [\*CertificatesConfiguration](#CertificatesConfiguration) |
+| `imagePullSecrets ` | The list of pull secrets to be used to pull the images. If the license key contains a pull secret that secret will be automatically included. | [\[\]LocalObjectReference](#LocalObjectReference) |
+| `storage ` | Configuration of the storage of the instances | [StorageConfiguration](#StorageConfiguration) |
+| `startDelay ` | The time in seconds that is allowed for a PostgreSQL instance to successfully start up (default 30) | int32 |
+| `stopDelay ` | The time in seconds that is allowed for a PostgreSQL instance node to gracefully shutdown (default 30) | int32 |
+| `affinity ` | Affinity/Anti-affinity rules for Pods | [AffinityConfiguration](#AffinityConfiguration) |
+| `resources ` | Resources requirements of every generated Pod. Please refer to | [ScheduledBackupSpec](#ScheduledBackupSpec) |
+| `status ` | Most recently observed status of the ScheduledBackup. This data may not be up to date. Populated by the system. Read-only. More info: | [ScheduledBackupStatus](#ScheduledBackupStatus) |
| [metav1.ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta) |
+| `items ` | List of clusters - *mandatory* | [\[\]ScheduledBackup](#ScheduledBackup) |
. - *mandatory* | string |
+| `cluster ` | The cluster to backup | [LocalObjectReference](#LocalObjectReference) |
:9187/metrics
All monitoring queries that are performed on PostgreSQL are:
-- transactionally atomic (one transaction per query)
-- executed with the `pg_monitor` role
-- executed with `application_name` set to `cnp_metrics_exporter`
-- executed as user `postgres`
+- transactionally atomic (one transaction per query)
+- executed with the `pg_monitor` role
+- executed with `application_name` set to `cnp_metrics_exporter`
+- executed as user `postgres`
Please refer to the "Default roles" section in PostgreSQL
[documentation](https://www.postgresql.org/docs/current/default-roles.html)
@@ -34,9 +34,9 @@ Queries, by default, are run against the *main database*, as defined by
the specified `bootstrap` method of the `Cluster` resource, according
to the following logic:
-- using `initdb`: queries will be run against the specified database by default, so the
- value passed as `initdb.database` or defaulting to `app` if not specified.
-- not using `initdb`: queries will run against the `postgres` database, by default.
+- using `initdb`: queries will be run against the specified database by default, so the
+ value passed as `initdb.database` or defaulting to `app` if not specified.
+- not using `initdb`: queries will run against the `postgres` database, by default.
The default database can always be overridden for a given user-defined metric,
by specifying a list of one or more databases in the `target_databases` option.
@@ -70,16 +70,16 @@ spec:
Every PostgreSQL instance exporter automatically exposes a set of predefined
metrics, which can be classified in two major categories:
-- PostgreSQL related metrics, starting with `cnp_collector_*`, including:
+- PostgreSQL related metrics, starting with `cnp_collector_*`, including:
- - number of WAL files and total size on disk
- - number of `.ready` and `.done` files in the archive status folder
- - requested minimum and maximum number of synchronous replicas, as well as
- the expected and actually observed values
- - flag indicating if replica cluster mode is enabled or disabled
- - flag indicating if a manual switchover is required
+ - number of WAL files and total size on disk
+ - number of `.ready` and `.done` files in the archive status folder
+ - requested minimum and maximum number of synchronous replicas, as well as
+ the expected and actually observed values
+ - flag indicating if replica cluster mode is enabled or disabled
+ - flag indicating if a manual switchover is required
-- Go runtime related metrics, starting with `go_*`
+- Go runtime related metrics, starting with `go_*`
Below is a sample of the metrics returned by the `localhost:9187/metrics`
endpoint of an instance. As you can see, the Prometheus format is
@@ -250,6 +250,7 @@ go_memstats_sys_bytes 7.6891144e+07
# TYPE go_threads gauge
go_threads 18
```
+
### User defined metrics
This feature is currently in *beta* state and the format is inspired by the
@@ -415,33 +416,32 @@ Every custom query has the following basic structure:
Here is a short description of all the available fields:
-- ``: the name of the Prometheus metric
- - `query`: the SQL query to run on the target database to generate the metrics
- - `primary`: whether to run the query only on the primary instance
- - `master`: same as `primary` (for compatibility with the Prometheus PostgreSQL exporter's syntax - deprecated)
- - `runonserver`: a semantic version range to limit the versions of PostgreSQL the query should run on
- (e.g. `">=10.0.0"` or `">=12.0.0 <=14.0.0"`)
- - `target_databases`: a list of databases to run the `query` against,
- or a [shell-like pattern](#example-of-a-user-defined-metric-running-on-multiple-databases)
- to enable auto discovery. Overwrites the default database if provided.
- - `metrics`: section containing a list of all exported columns, defined as follows:
- - ``: the name of the column returned by the query
- - `usage`: one of the values described below
- - `description`: the metric's description
- - `metrics_mapping`: the optional column mapping when `usage` is set to `MAPPEDMETRIC`
+- ``: the name of the Prometheus metric
+ - `query`: the SQL query to run on the target database to generate the metrics
+ - `primary`: whether to run the query only on the primary instance
+ - `master`: same as `primary` (for compatibility with the Prometheus PostgreSQL exporter's syntax - deprecated)
+ - `runonserver`: a semantic version range to limit the versions of PostgreSQL the query should run on
+ (e.g. `">=10.0.0"` or `">=12.0.0 <=14.0.0"`)
+ - `target_databases`: a list of databases to run the `query` against,
+ or a [shell-like pattern](#example-of-a-user-defined-metric-running-on-multiple-databases)
+ to enable auto discovery. Overwrites the default database if provided.
+ - `metrics`: section containing a list of all exported columns, defined as follows:
+ - ``: the name of the column returned by the query
+ - `usage`: one of the values described below
+ - `description`: the metric's description
+ - `metrics_mapping`: the optional column mapping when `usage` is set to `MAPPEDMETRIC`
The possible values for `usage` are:
-| Column Usage Label | Description |
-|:--------------------|:---------------------------------------------------------|
-| `DISCARD` | this column should be ignored |
-| `LABEL` | use this column as a label |
-| `COUNTER` | use this column as a counter |
-| `GAUGE` | use this column as a gauge |
-| `MAPPEDMETRIC` | use this column with the supplied mapping of text values |
-| `DURATION` | use this column as a text duration (in milliseconds) |
-| `HISTOGRAM` | use this column as a histogram |
-
+| Column Usage Label | Description |
+| :----------------- | :------------------------------------------------------- |
+| `DISCARD` | this column should be ignored |
+| `LABEL` | use this column as a label |
+| `COUNTER` | use this column as a counter |
+| `GAUGE` | use this column as a gauge |
+| `MAPPEDMETRIC` | use this column with the supplied mapping of text values |
+| `DURATION` | use this column as a text duration (in milliseconds) |
+| `HISTOGRAM` | use this column as a histogram |
Please visit the ["Metric Types" page](https://prometheus.io/docs/concepts/metric_types/)
from the Prometheus documentation for more information.
@@ -458,7 +458,6 @@ cnp__{= ... } :@sha256:` format, for more deterministic and
- repeatable deployments
+- Introduce the `pg_basebackup` bootstrap method to create a new PostgreSQL
+ cluster as a copy of an existing PostgreSQL instance of the same major
+ version, even outside Kubernetes
+- Add support for Kubernetes’ tolerations in the `Affinity` section of the
+ `Cluster` resource, allowing users to distribute PostgreSQL instances on
+ Kubernetes nodes with the required taint
+- Enable specification of a digest to an image name, through the
+ `:@sha256:` format, for more deterministic and
+ repeatable deployments
Security Enhancements:
-- Customize TLS certificates to authenticate the PostgreSQL server by defining
- secrets for the server certificate and the related Certification Authority
- that signed it
-- Raise the `sslmode` for the WAL receiver process of internal and
- automatically managed streaming replicas from `require` to `verify-ca`
+- Customize TLS certificates to authenticate the PostgreSQL server by defining
+ secrets for the server certificate and the related Certification Authority
+ that signed it
+- Raise the `sslmode` for the WAL receiver process of internal and
+ automatically managed streaming replicas from `require` to `verify-ca`
Changes:
-- Enhance the `promote` subcommand of the `cnp` plugin for `kubectl` to accept
- just the node number rather than the whole name of the pod
-- Adopt DNS-1035 validation scheme for cluster names (from which service names
- are inherited)
-- Enforce streaming replication connection when cloning a standby instance or
- when bootstrapping using the `pg_basebackup` method
-- Integrate the `Backup` resource with `beginWal`, `endWal`, `beginLSN`,
- `endLSN`, `startedAt` and `stoppedAt` regarding the physical base backup
-- Documentation improvements:
- - Provide a list of ports exposed by the operator and the operand container
- - Introduce the `cnp-bench` helm charts and guidelines for benchmarking the
- storage and PostgreSQL for database workloads
-- E2E tests enhancements:
- - Test Kubernetes 1.21
- - Add test for High Availability of the operator
- - Add test for node draining
-- Minor bug fixes, including:
- - Timeout to pg_ctl start during recovery operations too short
- - Operator not watching over direct events on PVCs
- - Fix handling of `immediateCheckpoint` and `jobs` parameter in
- `barmanObjectStore` backups
- - Empty logs when recovering from a backup
+- Enhance the `promote` subcommand of the `cnp` plugin for `kubectl` to accept
+ just the node number rather than the whole name of the pod
+- Adopt DNS-1035 validation scheme for cluster names (from which service names
+ are inherited)
+- Enforce streaming replication connection when cloning a standby instance or
+ when bootstrapping using the `pg_basebackup` method
+- Integrate the `Backup` resource with `beginWal`, `endWal`, `beginLSN`,
+ `endLSN`, `startedAt` and `stoppedAt` regarding the physical base backup
+- Documentation improvements:
+ - Provide a list of ports exposed by the operator and the operand container
+ - Introduce the `cnp-bench` helm charts and guidelines for benchmarking the
+ storage and PostgreSQL for database workloads
+- E2E tests enhancements:
+ - Test Kubernetes 1.21
+ - Add test for High Availability of the operator
+ - Add test for node draining
+- Minor bug fixes, including:
+ - Timeout to pg_ctl start during recovery operations too short
+ - Operator not watching over direct events on PVCs
+ - Fix handling of `immediateCheckpoint` and `jobs` parameter in
+ `barmanObjectStore` backups
+ - Empty logs when recovering from a backup
## Version 1.4.0
@@ -286,39 +301,39 @@ Changes:
Features:
-- Standard output logging of PostgreSQL error messages in JSON format
-- Provide a basic set of PostgreSQL metrics for the Prometheus exporter
-- Add the `restart` command to the `cnp` plugin for `kubectl` to restart
- the pods of a given PostgreSQL cluster in a rollout fashion
+- Standard output logging of PostgreSQL error messages in JSON format
+- Provide a basic set of PostgreSQL metrics for the Prometheus exporter
+- Add the `restart` command to the `cnp` plugin for `kubectl` to restart
+ the pods of a given PostgreSQL cluster in a rollout fashion
Security Enhancements:
-- Set `readOnlyRootFilesystem` security context for pods
+- Set `readOnlyRootFilesystem` security context for pods
Changes:
-- **IMPORTANT:** If you have previously deployed the Cloud Native PostgreSQL
- operator using the YAML manifest, you must delete the existing operator
- deployment before installing the new version. This is required to avoid
- conflicts with other Kubernetes API's due to a change in labels
- and label selectors being directly managed by the operator. Please refer to
- the Cloud Native PostgreSQL documentation for additional detail on upgrading
- to 1.4.0
-- Fix the labels that are automatically defined by the operator, renaming them
- from `control-plane: controller-manager` to
- `app.kubernetes.io/name: cloud-native-postgresql`
-- Assign the `metrics` name to the TCP port for the Prometheus exporter
-- Set `cnp_metrics_exporter` as the `application_name` to the metrics exporter
- connection in PostgreSQL
-- When available, use the application database for monitoring queries of the
- Prometheus exporter instead of the `postgres` database
-- Documentation improvements:
- - Customization of monitoring queries
- - Operator upgrade instructions
-- E2E tests enhancements
-- Minor bug fixes, including:
- - Avoid using `-R` when calling `pg_basebackup`
- - Remove stack trace from error log when getting the status
+- **IMPORTANT:** If you have previously deployed the Cloud Native PostgreSQL
+ operator using the YAML manifest, you must delete the existing operator
+ deployment before installing the new version. This is required to avoid
+ conflicts with other Kubernetes API's due to a change in labels
+ and label selectors being directly managed by the operator. Please refer to
+ the Cloud Native PostgreSQL documentation for additional detail on upgrading
+ to 1.4.0
+- Fix the labels that are automatically defined by the operator, renaming them
+ from `control-plane: controller-manager` to
+ `app.kubernetes.io/name: cloud-native-postgresql`
+- Assign the `metrics` name to the TCP port for the Prometheus exporter
+- Set `cnp_metrics_exporter` as the `application_name` to the metrics exporter
+ connection in PostgreSQL
+- When available, use the application database for monitoring queries of the
+ Prometheus exporter instead of the `postgres` database
+- Documentation improvements:
+ - Customization of monitoring queries
+ - Operator upgrade instructions
+- E2E tests enhancements
+- Minor bug fixes, including:
+ - Avoid using `-R` when calling `pg_basebackup`
+ - Remove stack trace from error log when getting the status
## Version 1.3.0
@@ -326,62 +341,62 @@ Changes:
Features:
-- Inheritance of labels and annotations
-- Set resource limits for every container
+- Inheritance of labels and annotations
+- Set resource limits for every container
Security Enhancements:
-- Support for restricted security context constraint on RedHat OpenShift to
- limit pod execution to a namespace allocated UID and SELinux context
-- Pod security contexts explicitly defined by the operator to run as
- non-root, non-privileged and without privilege escalation
+- Support for restricted security context constraint on RedHat OpenShift to
+ limit pod execution to a namespace allocated UID and SELinux context
+- Pod security contexts explicitly defined by the operator to run as
+ non-root, non-privileged and without privilege escalation
Changes:
-- Prometheus exporter endpoint listening on port 9187 (port 8000 is now
- reserved to instance coordination with API server)
-- Documentation improvements
-- E2E tests enhancements, including GKE environment
-- Minor bug fixes
+- Prometheus exporter endpoint listening on port 9187 (port 8000 is now
+ reserved to instance coordination with API server)
+- Documentation improvements
+- E2E tests enhancements, including GKE environment
+- Minor bug fixes
## Version 1.2.1
**Release date:** 6 Apr 2021
-- ScheduledBackup are no longer owners of the Backups, meaning that backups
- are not removed when ScheduledBackup objects are deleted
-- Update on ubi8-minimal image to solve RHSA-2021:1024 (Security Advisory: Important)
+- ScheduledBackup are no longer owners of the Backups, meaning that backups
+ are not removed when ScheduledBackup objects are deleted
+- Update on ubi8-minimal image to solve RHSA-2021:1024 (Security Advisory: Important)
## Version 1.2.0
**Release date:** 31 Mar 2021
-- Introduce experimental support for custom monitoring queries as ConfigMap and
- Secret objects using a compatible syntax with `postgres_exporter` for Prometheus
-- Support Operator Lifecycle Manager (OLM) deployments, with the subsequent
- presence on OperatorHub.io
-- Expand license key support for company-wide usage (previous restrictions limited only to a single cluster namespace)
-- Enhance container security by applying guidelines from the US Department of
- Defense (DoD)'s Defense Information Systems Agency (DISA) and the Center for
- Internet Security (CIS) and verifying them directly in the pipeline with
- Dockle
-- Improve E2E tests on AKS
-- Minor bug fixes
+- Introduce experimental support for custom monitoring queries as ConfigMap and
+ Secret objects using a compatible syntax with `postgres_exporter` for Prometheus
+- Support Operator Lifecycle Manager (OLM) deployments, with the subsequent
+ presence on OperatorHub.io
+- Expand license key support for company-wide usage (previous restrictions limited only to a single cluster namespace)
+- Enhance container security by applying guidelines from the US Department of
+ Defense (DoD)'s Defense Information Systems Agency (DISA) and the Center for
+ Internet Security (CIS) and verifying them directly in the pipeline with
+ Dockle
+- Improve E2E tests on AKS
+- Minor bug fixes
-## Version 1.1.0
+\## Version 1.1.0
**Release date:** 3 Mar 2021
-- Add `kubectl cnp status` to pretty-print the status of a cluster, including
- JSON and YAML output
-- Add `kubectl cnp certificate` to enable TLS authentication for client applications
-- Add the `-ro` service to route connections to the available hot
- standby replicas only, enabling offload of read-only queries from
- the cluster's primary instance
-- Rollback scaling down a cluster to a value lower than `maxSyncReplicas`
-- Request a checkpoint before demoting a former primary
-- Send `SIGINT` signal (fast shutdown) to PostgreSQL process on `SIGTERM`
-- Minor bug fixes
+- Add `kubectl cnp status` to pretty-print the status of a cluster, including
+ JSON and YAML output
+- Add `kubectl cnp certificate` to enable TLS authentication for client applications
+- Add the `-ro` service to route connections to the available hot
+ standby replicas only, enabling offload of read-only queries from
+ the cluster's primary instance
+- Rollback scaling down a cluster to a value lower than `maxSyncReplicas`
+- Request a checkpoint before demoting a former primary
+- Send `SIGINT` signal (fast shutdown) to PostgreSQL process on `SIGTERM`
+- Minor bug fixes
## Version 1.0.0
@@ -392,24 +407,24 @@ The first major stable release of Cloud Native PostgreSQL implements `Cluster`,
It uses these resources to create and manage PostgreSQL clusters inside
Kubernetes with the following main capabilities:
-- Direct integration with Kubernetes API server for High Availability, without
- requiring an external tool
-- Self-Healing capability, through:
- - failover of the primary instance by promoting the most aligned replica
- - automated recreation of a replica
-- Planned switchover of the primary instance by promoting a selected replica
-- Scale up/down capabilities
-- Definition of an arbitrary number of instances (minimum 1 - one primary server)
-- Definition of the *read-write* service to connect your applications to the
- only primary server of the cluster
-- Definition of the *read* service to connect your applications to any of the
- instances for reading workloads
-- Support for Local Persistent Volumes with PVC templates
-- Reuse of Persistent Volumes storage in Pods
-- Rolling updates for PostgreSQL minor versions and operator upgrades
-- TLS connections and client certificate authentication
-- Continuous backup to an S3 compatible object store
-- Full recovery and point-in-time recovery from an S3 compatible object store backup
-- Support for synchronous replicas
-- Support for node affinity via `nodeSelector` property
-- Standard output logging of PostgreSQL error messages
\ No newline at end of file
+- Direct integration with Kubernetes API server for High Availability, without
+ requiring an external tool
+- Self-Healing capability, through:
+ - failover of the primary instance by promoting the most aligned replica
+ - automated recreation of a replica
+- Planned switchover of the primary instance by promoting a selected replica
+- Scale up/down capabilities
+- Definition of an arbitrary number of instances (minimum 1 - one primary server)
+- Definition of the *read-write* service to connect your applications to the
+ only primary server of the cluster
+- Definition of the *read* service to connect your applications to any of the
+ instances for reading workloads
+- Support for Local Persistent Volumes with PVC templates
+- Reuse of Persistent Volumes storage in Pods
+- Rolling updates for PostgreSQL minor versions and operator upgrades
+- TLS connections and client certificate authentication
+- Continuous backup to an S3 compatible object store
+- Full recovery and point-in-time recovery from an S3 compatible object store backup
+- Support for synchronous replicas
+- Support for node affinity via `nodeSelector` property
+- Standard output logging of PostgreSQL error messages
\ No newline at end of file
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/replication.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/replication.mdx
index 6ff6f77c853..0b850013ccf 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/replication.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/replication.mdx
@@ -78,7 +78,6 @@ hostssl replication streaming_replica all cert
to the ["Certificates" section](certificates.md#client-streaming_replica-certificate)
in the documentation.
-
### Continuous backup integration
In case continuous backup is configured in the cluster, Cloud Native PostgreSQL
@@ -107,9 +106,9 @@ ANY q (pod1, pod2, ...)
Where:
-- `q` is an integer automatically calculated by the operator to be:
- `1 <= minSyncReplicas <= q <= maxSyncReplicas <= readyReplicas`
-- `pod1, pod2, ...` is the list of all PostgreSQL pods in the cluster
+- `q` is an integer automatically calculated by the operator to be:
+ `1 <= minSyncReplicas <= q <= maxSyncReplicas <= readyReplicas`
+- `pod1, pod2, ...` is the list of all PostgreSQL pods in the cluster
!!! Warning
To provide self-healing capabilities, the operator has the power
@@ -140,14 +139,14 @@ can be a primary cluster or another replica cluster (cascading replica cluster).
The available options in terms of replication, both at bootstrap and continuous
recovery level, are:
-- use streaming replication between the replica cluster and the source
- (this will certainly require some administrative and security related
- work to be done to make sure that the network connection between the
- two clusters is correctly setup)
-- use a Barman Cloud object store for recovery of the base backups and
- the WAL files that are regularly shipped from the source to the object
- store and pulled by `barman-cloud-wal-restore` in the replica cluster
-- any of the two
+- use streaming replication between the replica cluster and the source
+ (this will certainly require some administrative and security related
+ work to be done to make sure that the network connection between the
+ two clusters is correctly setup)
+- use a Barman Cloud object store for recovery of the base backups and
+ the WAL files that are regularly shipped from the source to the object
+ store and pulled by `barman-cloud-wal-restore` in the replica cluster
+- any of the two
All you have to do is actually define an external cluster.
Please refer to the ["Bootstrap" section](bootstrap.md#bootstrap-from-another-cluster)
@@ -156,18 +155,18 @@ for information on how to clone a PostgreSQL server using either
If the external cluster contains a `barmanObjectStore` section:
-- you'll be able to boostrap the replica cluster from an object store
- using the `recovery` section
-- Cloud Native PostgreSQL will automatically set the `restore_command`
- in the designated primary instance
+- you'll be able to boostrap the replica cluster from an object store
+ using the `recovery` section
+- Cloud Native PostgreSQL will automatically set the `restore_command`
+ in the designated primary instance
If the external cluster contains a `connectionParameters` section:
-- you'll be able to boostrap the replica cluster via streaming replication
- using the `pg_basebackup` section
-- Cloud Native PostgreSQL will automatically set the `primary_conninfo`
- option in the designated primary instance, so that a WAL receiver
- process is started to connect to the source cluster and receive data
+- you'll be able to boostrap the replica cluster via streaming replication
+ using the `pg_basebackup` section
+- Cloud Native PostgreSQL will automatically set the `primary_conninfo`
+ option in the designated primary instance, so that a WAL receiver
+ process is started to connect to the source cluster and receive data
The created replica cluster can perform backups in a reserved object store from
the designated primary, enabling symmetric architectures in a distributed
@@ -176,10 +175,10 @@ fashion.
You have full flexibility and freedom to decide your favourite
distributed architecture for a PostgreSQL database, by choosing:
-- a private cloud spanning over multiple Kubernetes clusters in different data
- centers
-- a public cloud spanning over multiple Kubernetes clusters in different
- regions
-- a mix of the previous two (hybrid)
-- a public cloud spanning over multiple Kubernetes clusters in different
- regions and on different Cloud Service Providers
\ No newline at end of file
+- a private cloud spanning over multiple Kubernetes clusters in different data
+ centers
+- a public cloud spanning over multiple Kubernetes clusters in different
+ regions
+- a mix of the previous two (hybrid)
+- a public cloud spanning over multiple Kubernetes clusters in different
+ regions and on different Cloud Service Providers
\ No newline at end of file
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/resource_management.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/resource_management.mdx
index daec60d53cf..7f43a6e79ac 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/resource_management.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/resource_management.mdx
@@ -10,8 +10,8 @@ they might be allowed to use as much CPU and RAM as needed.
Cloud Native PostgreSQL allows administrators to control and manage resource usage by the pods of the cluster,
through the `resources` section of the manifest, with two knobs:
-- `requests`: initial requirement
-- `limits`: maximum usage, in case of dynamic increase of resource needs
+- `requests`: initial requirement
+- `limits`: maximum usage, in case of dynamic increase of resource needs
For example, you can request an initial amount of RAM of 32MiB (scalable to 128MiB) and 50m of CPU (scalable to 100m)
as follows:
@@ -34,9 +34,9 @@ available memory to satisfy the pod's memory request.
For each resource, we divide containers into 3 Quality of Service (QoS) classes, in decreasing order of priority:
-- *Guaranteed*
-- *Burstable*
-- *Best-Effort*
+- *Guaranteed*
+- *Burstable*
+- *Best-Effort*
For more details, please refer to the ["Configure Quality of Service for Pods"](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes)
section in the Kubernetes documentation.
@@ -46,16 +46,16 @@ For a PostgreSQL workload it is recommended to set a "Guaranteed" QoS.
To avoid resources related issues in Kubernetes, we can refer to the best practices for "out of resource" handling
while creating a cluster:
-- Specify your required values for memory and CPU in the resources section of the manifest file.
- This way, you can avoid the `OOM Killed` (where "OOM" stands for Out Of Memory) and `CPU throttle` or any other
- resource-related issues on running instances.
-- For your cluster's pods to get assigned to the "Guaranteed" QoS class, you must set limits and requests
- for both memory and CPU to the same value.
-- Specify your required PostgreSQL memory parameters consistently with the pod resources (as you would do
- in a VM or physical machine scenario - see below).
-- Set up database server pods on a dedicated node using nodeSelector.
- See the "nodeSelector" and "tolerations" fields of the
- [“affinityconfiguration"](api_reference.md#affinityconfiguration) resource on the API reference page.
+- Specify your required values for memory and CPU in the resources section of the manifest file.
+ This way, you can avoid the `OOM Killed` (where "OOM" stands for Out Of Memory) and `CPU throttle` or any other
+ resource-related issues on running instances.
+- For your cluster's pods to get assigned to the "Guaranteed" QoS class, you must set limits and requests
+ for both memory and CPU to the same value.
+- Specify your required PostgreSQL memory parameters consistently with the pod resources (as you would do
+ in a VM or physical machine scenario - see below).
+- Set up database server pods on a dedicated node using nodeSelector.
+ See the "nodeSelector" and "tolerations" fields of the
+ [“affinityconfiguration"](api_reference.md#affinityconfiguration) resource on the API reference page.
You can refer to the following example manifest:
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/rolling_update.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/rolling_update.mdx
index 60d33f862e5..5a5ec050b5b 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/rolling_update.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/rolling_update.mdx
@@ -12,13 +12,13 @@ applications are running against it.
Rolling upgrades are started when:
-- the user changes the `imageName` attribute of the cluster specification;
+- the user changes the `imageName` attribute of the cluster specification;
-- after the operator is updated, to ensure the Pods run the latest instance
- manager;
+- after the operator is updated, to ensure the Pods run the latest instance
+ manager;
-- when a change in the PostgreSQL configuration requires a restart to be
- applied.
+- when a change in the PostgreSQL configuration requires a restart to be
+ applied.
The operator starts upgrading all the replicas, one Pod at a time, starting
from the one with the highest serial.
@@ -26,15 +26,15 @@ from the one with the highest serial.
The primary is the last node to be upgraded. This operation is configurable and
managed by the `primaryUpdateStrategy` option, accepting these two values:
-- `unsupervised`: the rolling update process is managed by Kubernetes
- and is entirely automated, with the *switchover* operation
- starting once all the replicas have been upgraded
-- `supervised`: the rolling update process is suspended immediately
- after all replicas have been upgraded and can only be completed
- with a manual switchover triggered by an administrator with
- `kubectl cnp promote [cluster] [pod]`. The plugin can be downloaded from the
- [`kubectl-cnp` project page](https://github.com/EnterpriseDB/kubectl-cnp)
- on GitHub.
+- `unsupervised`: the rolling update process is managed by Kubernetes
+ and is entirely automated, with the *switchover* operation
+ starting once all the replicas have been upgraded
+- `supervised`: the rolling update process is suspended immediately
+ after all replicas have been upgraded and can only be completed
+ with a manual switchover triggered by an administrator with
+ `kubectl cnp promote [cluster] [pod]`. The plugin can be downloaded from the
+ [`kubectl-cnp` project page](https://github.com/EnterpriseDB/kubectl-cnp)
+ on GitHub.
The default and recommended value is `unsupervised`.
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/samples.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/samples.mdx
index 1ee3ab398e7..7abbe69d626 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/samples.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/samples.mdx
@@ -6,17 +6,17 @@ product: 'Cloud Native Operator'
In this section, you can find some examples of configuration files to set up your PostgreSQL `Cluster`.
-* [`cluster-example.yaml`](../samples/cluster-example.yaml):
- a basic example of `Cluster` that uses the default storage class. For demonstration and experimentation purposes
- on a personal Kubernetes cluster with Minikube or Kind as described in the ["Quickstart"](quickstart.md).
-* [`cluster-example-custom.yaml`](../samples/cluster-example-custom.yaml):
- a basic example of `Cluster` that uses the default storage class and custom parameters for `postgresql.conf` and
- `pg_hba.conf` files
-* [`cluster-storage-class.yaml`](../samples/cluster-storage-class.yaml):
- a basic example of `Cluster` that uses a specified storage class.
-* [`cluster-pvc-template.yaml`](../samples/cluster-pvc-template.yaml):
- a basic example of `Cluster` that uses a persistent volume claim template.
-* [`cluster-example-full.yaml`](../samples/cluster-example-full.yaml):
- an example of `Cluster` that sets most of the available options.
+- [`cluster-example.yaml`](../samples/cluster-example.yaml):
+ a basic example of `Cluster` that uses the default storage class. For demonstration and experimentation purposes
+ on a personal Kubernetes cluster with Minikube or Kind as described in the ["Quickstart"](quickstart.md).
+- [`cluster-example-custom.yaml`](../samples/cluster-example-custom.yaml):
+ a basic example of `Cluster` that uses the default storage class and custom parameters for `postgresql.conf` and
+ `pg_hba.conf` files
+- [`cluster-storage-class.yaml`](../samples/cluster-storage-class.yaml):
+ a basic example of `Cluster` that uses a specified storage class.
+- [`cluster-pvc-template.yaml`](../samples/cluster-pvc-template.yaml):
+ a basic example of `Cluster` that uses a persistent volume claim template.
+- [`cluster-example-full.yaml`](../samples/cluster-example-full.yaml):
+ an example of `Cluster` that sets most of the available options.
For a list of available options, please refer to the ["API Reference" page](api_reference.md).
\ No newline at end of file
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/scheduling.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/scheduling.mdx
index 885e022bc35..4d33d1a01b3 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/scheduling.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/scheduling.mdx
@@ -18,9 +18,9 @@ You can control how the Cloud Native PostgreSQL cluster's instances should be
scheduled through the [`affinity`](api_reference.md#AffinityConfiguration)
section in the definition of the cluster, which supports:
-- pod affinity/anti-affinity
-- node selectors
-- tolerations
+- pod affinity/anti-affinity
+- node selectors
+- tolerations
!!! Info
Cloud Native PostgreSQL does not support pod templates for finer control
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/security.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/security.mdx
index 75eb54d0bbe..f0fac197f55 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/security.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/security.mdx
@@ -44,10 +44,10 @@ Every container image that is part of Cloud Native PostgreSQL is automatically b
Such images include not only the operator's, but also the operands' - specifically every supported PostgreSQL and EDB Postgres Advanced version.
Within the pipelines, images are scanned with:
-- [Dockle](https://github.com/goodwithtech/dockle): for best practices in terms
- of the container build process
-- [Clair](https://github.com/quay/clair): for vulnerabilities found in both the
- underlying operating system as well as libraries and applications that they run
+- [Dockle](https://github.com/goodwithtech/dockle): for best practices in terms
+ of the container build process
+- [Clair](https://github.com/quay/clair): for vulnerabilities found in both the
+ underlying operating system as well as libraries and applications that they run
!!! Important
All operand images are automatically rebuilt once a day by our pipelines in case
@@ -56,10 +56,10 @@ Within the pipelines, images are scanned with:
The following guidelines and frameworks have been taken into account for container-level security:
-- the ["Container Image Creation and Deployment Guide"](https://dl.dod.cyber.mil/wp-content/uploads/devsecops/pdf/DevSecOps_Enterprise_Container_Image_Creation_and_Deployment_Guide_2.6-Public-Release.pdf),
- developed by the Defense Information Systems Agency (DISA) of the United States Department of Defense (DoD)
-- the ["CIS Benchmark for Docker"](https://www.cisecurity.org/benchmark/docker/),
- developed by the Center for Internet Security (CIS)
+- the ["Container Image Creation and Deployment Guide"](https://dl.dod.cyber.mil/wp-content/uploads/devsecops/pdf/DevSecOps_Enterprise_Container_Image_Creation_and_Deployment_Guide_2.6-Public-Release.pdf),
+ developed by the Defense Information Systems Agency (DISA) of the United States Department of Defense (DoD)
+- the ["CIS Benchmark for Docker"](https://www.cisecurity.org/benchmark/docker/),
+ developed by the Center for Internet Security (CIS)
!!! Seealso "About the Container level security"
Please refer to ["Security and Containers in Cloud Native PostgreSQL"](https://www.enterprisedb.com/blog/security-and-containers-cloud-native-postgresql)
@@ -127,13 +127,13 @@ section of the Kubernetes documentation for further information.
Cloud Native PostgreSQL exposes ports at operator, instance manager and operand
levels, as listed in the table below:
-System | Port number | Exposing | Name | Certificates | Authentication
-:--------------- | :----------- | :------------------ | :------------------ | :------------ | :--------------
-operator | 9443 | webhook server | `webhook-server` | TLS | Yes
-operator | 8080 | metrics | `metrics` | no TLS | No
-instance manager | 9187 | metrics | `metrics` | no TLS | No
-instance manager | 8000 | status | `status` | no TLS | No
-operand | 5432 | PostgreSQL instance | `postgresql` | optional TLS | Yes
+| System | Port number | Exposing | Name | Certificates | Authentication |
+| :--------------- | :---------- | :------------------ | :--------------- | :----------- | :------------- |
+| operator | 9443 | webhook server | `webhook-server` | TLS | Yes |
+| operator | 8080 | metrics | `metrics` | no TLS | No |
+| instance manager | 9187 | metrics | `metrics` | no TLS | No |
+| instance manager | 8000 | status | `status` | no TLS | No |
+| operand | 5432 | PostgreSQL instance | `postgresql` | optional TLS | Yes |
### PostgreSQL
@@ -157,7 +157,7 @@ By default, every replica is automatically configured to connect in **physical
async streaming replication** with the current primary instance, with a special
user called `streaming_replica`. The connection between nodes is **encrypted**
and authentication is via **TLS client certificates** (please refer to the
-["Client TLS/SSL Connections"](ssl_connections.md#Client TLS/SSL Connections) page
+["Client TLS/SSL Connections"]\(ssl_connections.md#Client TLS/SSL Connections) page
for details).
Currently, the operator allows administrators to add `pg_hba.conf` lines directly in the manifest
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/ssl_connections.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/ssl_connections.mdx
index 78814bff39b..b8b2c25f4fe 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/ssl_connections.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/ssl_connections.mdx
@@ -125,10 +125,10 @@ spec:
This Pod will mount secrets managed by the Cloud Native PostgreSQL operator, including:
-* `sslcert`: the TLS client public certificate
-* `sslkey`: the TLS client certificate private key
-* `sslrootcert`: the TLS Certification Authority certificate, that signed the certificate on
- the server to be used to verify the identity of the instances
+- `sslcert`: the TLS client public certificate
+- `sslkey`: the TLS client certificate private key
+- `sslrootcert`: the TLS Certification Authority certificate, that signed the certificate on
+ the server to be used to verify the identity of the instances
They will be used to create the default resources that `psql` (and other libpq based applications like `pgbench`)
requires to establish a TLS encrypted connection to the Postgres database.
diff --git a/advocacy_docs/kubernetes/cloud_native_postgresql/storage.mdx b/advocacy_docs/kubernetes/cloud_native_postgresql/storage.mdx
index 0f1469cee26..adc8f70e677 100644
--- a/advocacy_docs/kubernetes/cloud_native_postgresql/storage.mdx
+++ b/advocacy_docs/kubernetes/cloud_native_postgresql/storage.mdx
@@ -20,8 +20,8 @@ and bare metal, are also valid in container contexts managed by Kubernetes.
There are two primary methods of access to storage:
-- **network**: either directly or indirectly (think of an NFS volume locally mounted on a host running Kubernetes)
-- **local**: directly attached to the node where a Pod is running (this also includes directly attached disks on bare metal installations of Kubernetes)
+- **network**: either directly or indirectly (think of an NFS volume locally mounted on a host running Kubernetes)
+- **local**: directly attached to the node where a Pod is running (this also includes directly attached disks on bare metal installations of Kubernetes)
Network storage, which is the most common usage pattern in Kubernetes,
presents the same issues of throughput and latency that you can
@@ -48,11 +48,11 @@ in a controlled Kubernetes environment, before deploying the database in product
Briefly, `cnp-bench` is designed to operate at two levels:
-- measuring the performance of the underlying storage using `fio`, with relevant
- metrics for database workloads such as throughput for sequential reads, sequential
- writes, random reads and random writes
-- measuring the performance of the database using the default benchmarking tool
- distributed along with PostgreSQL: `pgbench`
+- measuring the performance of the underlying storage using `fio`, with relevant
+ metrics for database workloads such as throughput for sequential reads, sequential
+ writes, random reads and random writes
+- measuring the performance of the database using the default benchmarking tool
+ distributed along with PostgreSQL: `pgbench`
!!! Important
Measuring both the storage and database performance is an activity that
diff --git a/product_docs/docs/bdr/3.7/backup.mdx b/product_docs/docs/bdr/3.7/backup.mdx
index 1d384cdffce..8a749aa6dac 100644
--- a/product_docs/docs/bdr/3.7/backup.mdx
+++ b/product_docs/docs/bdr/3.7/backup.mdx
@@ -4,4 +4,290 @@ originalFilePath: backup.md
---
-
+
+4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
+ endorse or promote products derived from this software without
+ prior written permission. For written permission, please contact
+ openssl-coreopenssl.org.
+
+5. Products derived from this software may not be called "OpenSSL"
+ nor may "OpenSSL" appear in their names without prior written
+ permission of the OpenSSL Project.
+
+6. Redistributions of any form whatsoever must retain the following
+ acknowledgment:
+ "This product includes software developed by the OpenSSL Project
+ for use in the OpenSSL Toolkit (
+
+THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT \`\`AS IS'' AND ANY
+EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
+ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGE.
+
+====================================================================
+
+This product includes cryptographic software written by Eric Young
+(eaycryptsoft.com). This product includes software written by Tim
+Hudson (tjhcryptsoft.com).
+
+## Original SSLeay Licence
+
+Copyright © 1995-1998 Eric Young (eaycryptsoft.com)
+All rights reserved.
+
+This package is an SSL implementation written
+by Eric Young (eaycryptsoft.com).
+The implementation was written so as to conform with Netscapes SSL.
+
+This library is free for commercial and non-commercial use as long as
+the following conditions are aheared to. The following conditions
+apply to all code found in this distribution, be it the RC4, RSA,
+lhash, DES, etc., code; not just the SSL code. The SSL documentation
+included with this distribution is covered by the same copyright terms
+except that the holder is Tim Hudson (tjhcryptsoft.com).
+
+Copyright remains Eric Young's, and as such any Copyright notices in
+the code are not to be removed.
+If this package is used in a product, Eric Young should be given attribution
+as the author of the parts of the library used.
+This can be in the form of a textual message at program startup or
+in documentation (online or textual) provided with the package.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the copyright
+ notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+3. All advertising materials mentioning features or use of this software
+ must display the following acknowledgement:
+ "This product includes cryptographic software written by
+ Eric Young (eaycryptsoft.com)"
+ The word 'cryptographic' can be left out if the rouines from the library
+ being used are not cryptographic related :-).
+4. If you include any Windows specific code (or a derivative thereof) from
+ the apps directory (application code) you must include an acknowledgement:
+ "This product includes software written by Tim Hudson (tjhcryptsoft.com)"
+
+THIS SOFTWARE IS PROVIDED BY ERIC YOUNG \`\`AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The licence and distribution terms for any publically available version or
+derivative of this code cannot be changed. i.e. this code cannot simply be
+copied and put under another distribution licence
+[including the GNU Public Licence.]
+
+## PostgreSQL License
+
+PostgreSQL Database Management System
+(formerly known as Postgres, then as Postgres95)
+
+Portions Copyright © 1996-2020, The PostgreSQL Global Development Group
+
+Portions Copyright © 1994, The Regents of the University of California
+
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose, without fee, and without a written agreement
+is hereby granted, provided that the above copyright notice and this paragraph
+and the following two paragraphs appear in all copies.
+
+IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
+DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
+LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION,
+EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING,
+BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS,
+AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
+SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
diff --git a/product_docs/docs/bdr/3.7/repsets.mdx b/product_docs/docs/bdr/3.7/repsets.mdx
index 6e89d3af86a..54792b1035f 100644
--- a/product_docs/docs/bdr/3.7/repsets.mdx
+++ b/product_docs/docs/bdr/3.7/repsets.mdx
@@ -4,4 +4,670 @@ originalFilePath: repsets.md
---
-VIDEO
-## Virtual Machine Quota Requirements
+## Virtual machine quota requirements
In each region, EDB Cloud uses six ESv3 and six DSv2 virtual machine cores to manage your EDB Cloud infrastructure.
Your Postgres clusters deployed in the region use separate ESv3 virtual machine cores.
The number of cores depends on the Instance Type and High Availability options of the clusters you provision. You can calculate the number of ESv3 cores required for your cluster based on the following:
@@ -21,7 +21,7 @@ The number of cores depends on the Instance Type and High Availability options o
As an example, if you provision the largest virtual machine E64Sv3 with high availability enabled, it requires (3 * 64)=192 ESv3 cores per region. EDB Cloud infrastructure requires an additional six ESv3 and six DSv2 virtual machine cores per region.
-## Checking Current Utilization
+## Checking current utilization
To check if you have adequate Azure resources to provision new clusters:
@@ -33,7 +33,7 @@ To check if you have adequate Azure resources to provision new clusters:
6. Search for Public IP to view networks limits.
-## Increasing Network Quota
+## Increasing network quota
You can increase the number of public IP addresses for your account either by using Azure's portal if you have appropriate privileges or by submitting a support request. See:
@@ -42,7 +42,7 @@ You can increase the number of public IP addresses for your account either by us
- [Request networking quota increase at subscription level using Usages + quotas](https://docs.microsoft.com/en-us/azure/azure-portal/supportability/networking-quota-requests#request-networking-quota-increase-at-subscription-level-using-usages--quotas)
-## Increasing Virtual Machine Quota
+## Increasing virtual machine quota
You can increase the number of ESv3 Series virtual machines per region for your account either by using Azure's portal if you have appropriate privileges or by submitting a support request. See:
diff --git a/product_docs/docs/edbcloud/beta/getting_started/02_connect_cloud_account.mdx b/product_docs/docs/edbcloud/beta/getting_started/02_connect_cloud_account.mdx
index 4c20f49c0fa..3b893b9d097 100644
--- a/product_docs/docs/edbcloud/beta/getting_started/02_connect_cloud_account.mdx
+++ b/product_docs/docs/edbcloud/beta/getting_started/02_connect_cloud_account.mdx
@@ -1,16 +1,16 @@
---
-title: "Connecting Your Cloud Account"
+title: "Connecting your EDB Cloud account"
---
This topic describes how to set up your EDB Cloud account on Azure Marketplace. Your Azure subscription for EDB Cloud is where you create and manage Postgres clusters.
-## Before You Connect Your Cloud Account
+## Before you connect your cloud account
1. Ensure you have an active Microsoft Azure subscription. If you need to create one, see [Create an additional Azure subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription).
1. Within Azure Active Directory, ensure your role is owner and your user type is member (not guest) for the subscription you are using.
-1. Create an Azure Active Directory Application client to delegate Identity and Access Management functions to Azure Active Directory (AD). You can create the Azure Active Directory Application using the Azure Portal, but a simpler and less error-prone approach is to use the `create-spn` script (see [Create Azure Active Directory Application Using `create-spn`](#create-azure-active-directory-application-using-create-spn)). The script approach requires the Azure API.
+1. Create an Azure Active Directory Application client to delegate Identity and Access Management functions to Azure Active Directory (AD). You can create the Azure Active Directory Application using the Azure Portal, but a simpler and less error-prone approach is to use the `create-spn` script (see [Create Azure Active Directory Application using `create-spn`](#create-azure-active-directory-application-using-create-spn)). The script approach requires the Azure API.
!!! Note
Some steps of the subscription process require approval of an Azure AD global administrator.
@@ -18,7 +18,7 @@ This topic describes how to set up your EDB Cloud account on Azure Marketplace.
-### Create Azure Active Directory Application Using Azure Portal
+### Create Azure Active Directory Application using the Azure portal
!!! Note
Create your Azure AD Application in the same tenant as the subscription you want it associated with.
@@ -31,7 +31,7 @@ Take note of the **Application (client) ID**, you need it to configure your EDB
1. Choose _application secret_ as an authentication option for the application. See [Create a new Azure AD application secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#option-2-create-a-new-application-secret) for instructions. Take note of the Azure AD App Secret, you need it to configure your cloud account.
1. Assign the owner role to the application. See [Assign a role to the application](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#assign-a-role-to-the-application) for instructions. Enter the **Display name** of the Azure AD application in the **Select** field of the **Add role assignment** panel. See [Open the Add role assignment pane](https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal?tabs=current#step-2-open-the-add-role-assignment-pane) for instructions.
-### Create Azure Active Directory Application Using `create-spn`
+### Create Azure Active Directory Application using `create-spn`
To simplify the process of creating an Azure AD Application, EDB provides the [`create-spn`](https://github.com/EnterpriseDB/cloud-utilities/blob/main/azure/create-spn.sh) script for Azure API users. The script automates the manual steps described in the previous section. You can download it [here](https://github.com/EnterpriseDB/cloud-utilities/tree/main/azure).
Before using the script ensure that the following utilities are installed on your machine:
@@ -44,7 +44,7 @@ The syntax of the command is:
```
Flag and option details:
-| Flag/Option Shortcut | Flag/Option Long Name | Description |
+| Flag/option shortcut | Flag/option long name | Description |
| -------------------- | --------------------- | ----------- |
| -d *NAME* | --display-name *NAME* | Name of Azure AD Application |
| -s *SUBSCRIPTION_ID* | --subscription *SUBSCRIPTION_ID* | Azure Subscription ID used by EDB Cloud |
@@ -77,7 +77,7 @@ WARNING: 'name' property in the output is deprecated and will be removed in the
}
```
-## Connect Your Cloud Account
+## Connect your cloud account
To connect your cloud account with your Azure subscription:
@@ -117,15 +117,15 @@ To connect your cloud account with your Azure subscription:
11. Select **Submit.**
-## What's Next
+## What's next
### Login
You can now log in to your EDB Cloud account using your Azure AD identity if you filled in the parameters correctly.
-### Invite Users
+### Invite users
-You can invite new users by sharing the link to the EDB Cloud portal and having them log in with their Microsoft Azure Active Directory account. New users are not assigned any roles by default. After they log in the first time, you see them in the User list and are able to assign them a role with permissions to EDB Cloud. See [Assigning Roles to Users](../administering_cluster/01_portal_access/#assigning-roles-to-users) for instructions.
+You can invite new users by sharing the link to the EDB Cloud portal and having them log in with their Microsoft Azure Active Directory account. New users are not assigned any roles by default. After they log in the first time, you see them in the User list and are able to assign them a role with permissions to EDB Cloud. See [Assigning roles to users](../administering_cluster/01_portal_access/#assigning-roles-to-users) for instructions.
!!! Note
Azure AD email domain will likely be different than the email domain regularly used by your organization.
diff --git a/product_docs/docs/edbcloud/beta/getting_started/03_create_cluster.mdx b/product_docs/docs/edbcloud/beta/getting_started/03_create_cluster.mdx
index 65ffbc32846..f6da75f8b49 100644
--- a/product_docs/docs/edbcloud/beta/getting_started/03_create_cluster.mdx
+++ b/product_docs/docs/edbcloud/beta/getting_started/03_create_cluster.mdx
@@ -1,8 +1,8 @@
---
-title: "Creating a Cluster"
+title: "Creating a cluster"
---
!!! Note
-Prior to creating your cluster, make sure you have adequate Azure resources or your request to create a cluster will fail. See [Raising Your Azure Resource Limits](01_check_resource_limits).
+Prior to creating your cluster, make sure you have adequate Azure resources or your request to create a cluster will fail. See [Raising your Azure resource limits](01_check_resource_limits).
!!!
To create a cluster:
@@ -22,13 +22,13 @@ To create a cluster:
!!! Note
When you elect not to configure settings on optional tabs, the default values are used.
-## Cluster Info
+## Cluster Info tab
1. Enter the name for your cluster in the **Cluster Name** field.
2. Enter a password for your cluster in the **Password** field. This will be the password for the user edb_admin.
3. Select **Next: Operational Settings**.
-## Operational Settings
+## Operational Settings tab
1. In the **Database Type** section,
1. Select the type of Postgres you want to use in the **Postgres Type** field:
- [*PostgreSQL*](../../../supported-open-source/postgresql/) is an open-source object-relational database management system.
@@ -48,7 +48,7 @@ To create a cluster:
Private networking allows only IP addresses within your private network to connect to your cluster.
7. To optionally make updates to your database configuration parameters, select **Next: DB Configuration**.
-## DB Configuration
+## DB Configuration tab
In the **Parameters** section, you can update the value of the database configuration parameters, as needed.
To update the parameter values, see [Modifying Your Database Configuration Parameters](../using_cluster/03_modifying_your_cluster/05_db_configuration_parameters)
@@ -61,10 +61,10 @@ To update the parameter values, see [Modifying Your Database Configuration Param
Clusters are configured across availability zones in regions with availability zones. When high availability is disabled, only one instance is provisioned.
See [Supported Architectures](../overview/02_high_availibility) for more information.
-## What’s Next
+## What’s next
Now that you’ve created your cluster, here are some additional resources for cluster use and management:
-* [Using your Cluster]( ../using_cluster/)
-* [Managing Postgres Access](../../administering_cluster/02_postgres_access/)
+* [Using your cluster]( ../using_cluster/)
+* [Managing Postgres access](../../administering_cluster/02_postgres_access/)
diff --git a/product_docs/docs/edbcloud/beta/getting_started/index.mdx b/product_docs/docs/edbcloud/beta/getting_started/index.mdx
index 8e708fab683..e5010697056 100644
--- a/product_docs/docs/edbcloud/beta/getting_started/index.mdx
+++ b/product_docs/docs/edbcloud/beta/getting_started/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Getting Started"
+title: "Getting started"
indexCards: simple
---
diff --git a/product_docs/docs/edbcloud/beta/overview/02_high_availibility.mdx b/product_docs/docs/edbcloud/beta/overview/02_high_availibility.mdx
index be0be096111..7eb081f6a7d 100644
--- a/product_docs/docs/edbcloud/beta/overview/02_high_availibility.mdx
+++ b/product_docs/docs/edbcloud/beta/overview/02_high_availibility.mdx
@@ -1,10 +1,10 @@
---
-title: "Supported Architectures"
+title: "Supported architectures"
---
EDB Cloud enables deploying a cluster with or without high availability. The option is controlled with the **High Availablity** slide button on the [Create Cluster](https://portal.edbcloud.com/create-cluster) page in the [EDB Cloud](https://portal.edbcloud.com) portal.
-## High Availability - Enabled
+## High availability - enabled
The high availability option is provided to minimize downtime in cases of failures. High Availability clusters are configured automatically with - one _primary_ and two _replicas_ - with replicas staying up-to-date through physical streaming replication. In cloud regions with availability zones, clusters are provisioned across multiple availability zones to provide fault tolerance in the face of a datacenter failure
@@ -18,7 +18,7 @@ Incoming client connections are always routed to the current primary. In case of
By default, replication is synchronous to one replica and asynchronous to the other. That is, one replica must confirm that a transaction record was written to disk before the client receives acknowledgment of a successful commit. In PostgreSQL terms, `synchronous_commit` is set to `on` and `synchronous_standby_names` is set to `ANY 1 (replica-1, replica-2)`. This behavior can be modified on a per-transaction, per-session, per-user, or per-database basis with appropriate `SET` or `ALTER` commands.
-## High Availability - Not Enabled
+## High availability - not enabled
For non-production use cases where high availability is not a primary concern, a cluster deployment with high availability not enabled provides one primary with no standby servers for failover or read-only workloads.
diff --git a/product_docs/docs/edbcloud/beta/overview/03_security.mdx b/product_docs/docs/edbcloud/beta/overview/03_security.mdx
index a42c04cfcf9..00a191c3f87 100644
--- a/product_docs/docs/edbcloud/beta/overview/03_security.mdx
+++ b/product_docs/docs/edbcloud/beta/overview/03_security.mdx
@@ -3,12 +3,12 @@ title: "Security"
---
EDB Cloud runs in your own cloud account, isolates your data from other users, and gives you control over our access to it. The key security features are:
-- **Data Isolation:** Clusters are installed and managed in your cloud environment. Complete segregation of your data is ensured: your data never leaves your cloud account, and compromise of another EDB Cloud customer's systems does not put your data at risk.
+- **Data isolation:** Clusters are installed and managed in your cloud environment. Complete segregation of your data is ensured: your data never leaves your cloud account, and compromise of another EDB Cloud customer's systems does not put your data at risk.
-- **Granular Access Control:** You can use Single Sign On (SSO) and define your own sets of roles and Role Based Access Control (RBAC) policies to manage your individual cloud environments. See [Managing Portal Access](../administering_cluster/01_user_access) for more information.
-- **Data Encryption:** All data in EDB Cloud is encrypted in motion and at rest. Network traffic is encrypted using Transport Layer Security (TLS) v1.2 or greater, where applicable. Data at rest is encrypted using AES with 256 bit keys. Data encryption keys are envelope encrypted and the wrapped data encryption keys are securely stored in an Azure Key Vault instance in your account. Encryption keys never leave your environment.
-- **Portal Audit Logging:** Activities in the portal, such as those related to user roles, organization updates, and cluster creation and deletion are tracked automatically and viewed in the activity log.
-- **Database Logging and Auditing:** Functionality to track and analyze database activities is enabled automatically. For PostgreSQL, the PostgreSQL Audit Extension (pgAudit) is enabled automatically for you when deploying a Postgres cluster. For EDB Postgres Advanced Server, the EDB Audit extension (edbAudit) is enabled automatically for you.
+- **Granular access control:** You can use Single Sign On (SSO) and define your own sets of roles and Role Based Access Control (RBAC) policies to manage your individual cloud environments. See [Managing portal access](../administering_cluster/01_user_access) for more information.
+- **Data encryption:** All data in EDB Cloud is encrypted in motion and at rest. Network traffic is encrypted using Transport Layer Security (TLS) v1.2 or greater, where applicable. Data at rest is encrypted using AES with 256 bit keys. Data encryption keys are envelope encrypted and the wrapped data encryption keys are securely stored in an Azure Key Vault instance in your account. Encryption keys never leave your environment.
+- **Portal audit logging:** Activities in the portal, such as those related to user roles, organization updates, and cluster creation and deletion are tracked automatically and viewed in the activity log.
+- **Database logging and auditing:** Functionality to track and analyze database activities is enabled automatically. For PostgreSQL, the PostgreSQL Audit Extension (pgAudit) is enabled automatically for you when deploying a Postgres cluster. For EDB Postgres Advanced Server, the EDB Audit extension (edbAudit) is enabled automatically for you.
- **pgAudit:** The classes of statements being logged for pgAudit are set globally on a cluster with `pgaudit.log = 'write,ddl'`. The following statements made on tables will be logged by default when the cluster type is PostgreSQL: `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, AND `COPY`. All `DDL` will be logged.
-- **Database Cluster Permissions** The edb_admin account created during the _Create Cluster_ process includes the `CREATEDB` and `CREATEROLE` database roles. EDB recommends using the edb_admin account to create a new application user and new application database for further isolation. See [Managing Postgres Access](../administering_cluster/02_postgres_access) for more information.
+- **Database cluster permissions** The edb_admin account created during the *create cluster* process includes the `CREATEDB` and `CREATEROLE` database roles. EDB recommends using the edb_admin account to create a new application user and new application database for further isolation. See [Managing Postgres access](../administering_cluster/02_postgres_access) for more information.
diff --git a/product_docs/docs/edbcloud/beta/overview/04_responsibility_model.mdx b/product_docs/docs/edbcloud/beta/overview/04_responsibility_model.mdx
index 9a8621769cd..1ec47fe7c9e 100644
--- a/product_docs/docs/edbcloud/beta/overview/04_responsibility_model.mdx
+++ b/product_docs/docs/edbcloud/beta/overview/04_responsibility_model.mdx
@@ -1,18 +1,18 @@
---
-title: "Responsibility Model"
+title: "Responsibility model"
---
Security and confidentiality is a shared responsibility between you and EDB. EDB provides a secure platform that enables you to create and maintain secure database clusters deployed on EDB Cloud. You have numerous responsibilities around the security of your clusters and data held within them.
-The following Responsibility Model describes the distribution of specific responsibilities between you and EDB.
+The following responsibility model describes the distribution of specific responsibilities between you and EDB.
-## High Availability
+## High availability
- EDB is responsible for deploying clusters with one primary and two replicas. In cloud regions with availability zones, clusters will be deployed across multiple availability zones.
- You are responsible for choosing if you want to enable high availability.
-## Database Performance
+## Database performance
- EDB is responsible for managing and monitoring the underlying infrastructure resources.
- You are responsible for data modeling, query performance, and scaling the cluster to meet your performance needs.
@@ -20,7 +20,7 @@ The following Responsibility Model describes the distribution of specific respon
- EDB is responsible for managing and monitoring the underlying infrastructure.
- You are responsible for choosing the appropriate resources for your workload, including instance type, storage, and connections. You are also responsible for managing your Azure resource limits to ensure the underlying infrastructure can be scaled.
-## Backups and Restores
+## Backups and restores
- EDB is responsible for taking automatic backups and storing them in cross-regional Azure Blob Storage.
- You are responsible for periodically restoring and verifying the restores to ensure that archives are completing frequently and successfully to meet your needs.
@@ -28,6 +28,6 @@ The following Responsibility Model describes the distribution of specific respon
- EDB is responsible for data encryption at rest and in transit. EDB is also responsible for encrypting backups.
- You are responsible for column level encryption to protect sensitive database attributes from unauthorized access by authorized users and applications of the database.
-## Credential Management
+## Credential management
- EDB is responsible for making credentials available to customers.
- You are responsible for managing and securing your passwords, both for EDB Cloud and your database passwords.
diff --git a/product_docs/docs/edbcloud/beta/overview/05_database_version_policy.mdx b/product_docs/docs/edbcloud/beta/overview/05_database_version_policy.mdx
index 4257b3f9748..4b24abf71d2 100644
--- a/product_docs/docs/edbcloud/beta/overview/05_database_version_policy.mdx
+++ b/product_docs/docs/edbcloud/beta/overview/05_database_version_policy.mdx
@@ -1,23 +1,23 @@
---
-title: "Database Version Policy"
+title: "Database version policy"
---
-## Supported Postgres Types and Versions
+## Supported Postgres types and versions
-| **Postgres Type** | **Major Versions** |
+| **Postgres type** | **Major versions** |
| ----- | ------------------------- |
| PostgreSQL | 11 - 13 |
| EDB Postgres Advanced Server | 11 - 13 |
-## Major Version Support
+## Major version support
PostgreSQL and EDB Postgres Advanced Server major versions are supported from the date they are made available until the version is retired by EDB (generally 5 years). See [Platform Compatibility ](https://www.enterprisedb.com/product-compatibility#epas) for more details.
-## Minor Version Support
+## Minor version support
EDB performs periodic maintenance to ensure stability and security. EDB automatically performs minor version upgrades and patch updates as part of periodic maintenance. Customers are notified within the EDB Cloud portal prior to maintenance occurring. Minor versions are not user configurable.
diff --git a/product_docs/docs/edbcloud/beta/overview/06_support.mdx b/product_docs/docs/edbcloud/beta/overview/06_support.mdx
index 71de34c237e..b9b49307879 100644
--- a/product_docs/docs/edbcloud/beta/overview/06_support.mdx
+++ b/product_docs/docs/edbcloud/beta/overview/06_support.mdx
@@ -1,12 +1,12 @@
---
-title: "Support Options"
+title: "Support options"
---
If you experience problems with EDB Cloud, you have several options to engage with EDB's Support team to get help. If you have an EDB Cloud account, you can go directly to the Support portal or the EDB Cloud portal to open a support case, or you can leave Support a message using the Support Case widget.
If you can’t log in to your account, send us an email to [cloudsupport@enterprisedb.com](mailto:cloudsupport@enterprisedb.com).
-## Creating a Support Case From the Support Portal (recommended)
+## Creating a support case from the Support portal (recommended)
1. Initiate a support case using any one of these options:
@@ -21,7 +21,7 @@ If you can’t log in to your account, send us an email to [cloudsupport@enterpr
1. (Optional) Attach files to provide more details about the issue you're experiencing.
1. Select **Submit**.
-## Creating a Support Case From the Support Widget
+## Creating a support case from the **Support** widget
1. Log in to EDB Cloud and select **Support** on the bottom of the left navigation pane.
@@ -34,7 +34,7 @@ If you can’t log in to your account, send us an email to [cloudsupport@enterpr
6. (Optional) Attach files to provide more details about the issue you're experiencing.
7. Select **Submit**.
-## Case Severity Level
+## Case severity level
| Level | Description |
| -------- | ----------- |
diff --git a/product_docs/docs/edbcloud/beta/overview/index.mdx b/product_docs/docs/edbcloud/beta/overview/index.mdx
index e18a5d5c1aa..313409ac6a5 100644
--- a/product_docs/docs/edbcloud/beta/overview/index.mdx
+++ b/product_docs/docs/edbcloud/beta/overview/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Overview of Service"
+title: "Overview of service"
---
diff --git a/product_docs/docs/edbcloud/beta/pricing_and_billing/index.mdx b/product_docs/docs/edbcloud/beta/pricing_and_billing/index.mdx
index a79e94d3b83..b0a09961412 100644
--- a/product_docs/docs/edbcloud/beta/pricing_and_billing/index.mdx
+++ b/product_docs/docs/edbcloud/beta/pricing_and_billing/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Pricing and Billing "
+title: "Pricing and billing "
---
This section covers the pricing breakdown for EDB Cloud as well as how to view invoices and infrastructure usage through Microsoft Azure.
@@ -7,7 +7,7 @@ This section covers the pricing breakdown for EDB Cloud as well as how to view i
## Pricing
Pricing is based on the number of Virtual Central Processing Units (vCPUs) provisioned for the database software offering. Consumption of vCPUs is metered hourly. A deployment is comprised of either one instance or one primary and two replica instances of either PostgreSQL or EDB Postgres Advanced Server. When high availability is enabled, the number of vCPU per instance should be multiplied by three to calculate the full price for all resources used. See the full cost breakdown below:
-| Database Type | Hourly Price | Monthly Price* |
+| Database type | Hourly price | Monthly price* |
| --------------------- | -------------- | -------------- |
| PostgreSQL | $0.1655 / vCPU | $120.82 / vCPU |
| EDB Postgres Advanced Server | $0.2397 / vCPU | $174.98 / vCPU |
@@ -17,5 +17,5 @@ Pricing is based on the number of Virtual Central Processing Units (vCPUs) provi
## Billing
All billing is handled directly by Microsoft Azure. Invoices and usage can be viewed on the Azure Portal billing page. [Learn more](https://docs.microsoft.com/en-us/azure/cost-management-billing/)
-## Cloud Infrastructure Costs
+## Cloud infrastructure costs
EDB does not bill you for cloud infrastructure such as compute, storage, data transfer, monitoring, and logging. EDB Cloud clusters run in your Microsoft Azure account. Azure bills you directly for the cloud infrastructure provisioned according to the terms of your account agreement. Invoices and usage can be viewed on the Azure Portal billing page. [Learn more](https://docs.microsoft.com/en-us/azure/cost-management-billing/)
diff --git a/product_docs/docs/edbcloud/beta/reference/index.mdx b/product_docs/docs/edbcloud/beta/reference/index.mdx
index 638a2cb9fee..e0639d92680 100644
--- a/product_docs/docs/edbcloud/beta/reference/index.mdx
+++ b/product_docs/docs/edbcloud/beta/reference/index.mdx
@@ -14,10 +14,10 @@ To access the API, you need a token. The high-level steps to obtain a token are:
5. [Exchange for the raw token for the EDB Cloud token](#exchange-the-edbcloud-token-using-curl).
-EDB provides an optional script to simplify getting your device code and getting and refreshing your tokens. See [Using the `get-token` Script](#using-the-get-token-script) for details.
+EDB provides an optional script to simplify getting your device code and getting and refreshing your tokens. See [Using the `get-token` script](#using-the-get-token-script) for details.
-## Query the Authentication Endpoint
+## Query the authentication endpoint
This call returns the information that either:
@@ -49,7 +49,7 @@ AUDIENCE="https://portal.edbcloud.com/api"
```
The following example calls use these environment variables.
-## Request the Device Code Using `curl`
+## Request the device code using `curl`
!!!note
The `get-token` script executes this step. You don't need to make this call if you are using the script.
!!!
@@ -90,7 +90,7 @@ Store the device code in an environment variable for future use. For example:
DEVICE_CODE=KEOY2_5YjuVsRuIrrR-aq5gs
```
-## Authorize as a User
+## Authorize as a user
To authorize as a user:
@@ -103,9 +103,9 @@ To authorize as a user:
4. Log in with your Azure AD credentials.
-## Request the Raw Token Using `curl`
+## Request the raw token using `curl`
!!!note
- The `get-token` script executes this step. You don't need to make this call if you are using the script. See [Request Your Token Using `get-token`](#request-your-token-using-get-token).
+ The `get-token` script executes this step. You don't need to make this call if you are using the script. See [Request your token using `get-token`](#request-your-token-using-get-token).
!!!
The `curl --request POST` call requests a token. For example:
@@ -120,7 +120,7 @@ curl --request POST \
If successful, the call returns:
- `access_token` - use to exchange for the token to access EDB Cloud API.
-- `refresh_token` - use to obtain a new access token or ID token after the previous one has expired. (See [Refresh Tokens](https://auth0.com/docs/tokens/refresh-tokens) for more information.) Refresh tokens expire after 30 days.
+- `refresh_token` - use to obtain a new access token or ID token after the previous one has expired. (See [Refresh tokens](https://auth0.com/docs/tokens/refresh-tokens) for more information.) Refresh tokens expire after 30 days.
- `expires_in` - means the token expires after 24 hours since its creation.
@@ -159,7 +159,7 @@ If not successful, you receive one of the following errors:
The `get-token` script executes this step. You don't need to make this call if you are using the script.
!!!
-Use the raw token you obtained in the previous step [Request the Raw Token Using `curl`](#request-the-raw-token-using-curl) to get the EDB Cloud token:
+Use the raw token you obtained in the previous step [Request the raw token using `curl`](#request-the-raw-token-using-curl) to get the EDB Cloud token:
```
curl -s --request POST \
@@ -221,13 +221,13 @@ Example response:
```
-## Refresh your Token
+## Refresh your token
You use the refresh token to get a new raw access token. Usually you need a new access token only after the previous one expires or when gaining access to a new resource for the first time. You shouldn't call the endpoint to get a new access token every time you call an API. There are rate limits that throttle the amount of requests to the endpoint that can be executed using the same token from the same IP.
-### Refresh your Token Using `curl`
+### Refresh your t.oken Using `curl`
!!!note
-The `get-token` script has an option to execute this step. See [Refresh the Token Using `get-token`](#refresh-the-token-using-get-token).
+The `get-token` script has an option to execute this step. See [Refresh the token using `get-token`](#refresh-the-token-using-get-token).
!!!
If you are not using the `get-token` script to refresh your token, make a POST request to the `/oauth/token` endpoint in the Authentication API, using `grant_type=refresh_token`. For example:
@@ -269,7 +269,7 @@ The token you obtain from this step is the raw access token, you need to exchang
-## Using the `get-token` Script
+## Using the `get-token` script
To simplify the process of getting tokens, EDB provides the `get-token` script. You can download it [here](https://github.com/EnterpriseDB/cloud-utilities/tree/main/api).
@@ -278,7 +278,7 @@ To use the script, install the [jq command-line JSON processor](https://stedolan
Before running the script, [query the authentication endpoint](#query-the-authentication-endpoint).
-### get-token Usage
+### get-token usage
```
Get Tokens for EDB Cloud API
@@ -296,7 +296,7 @@ Usage:
Reference: https://www.enterprisedb.com/docs/edbcloud/latest/reference/
```
-### Request Your Token Using `get-token`
+### Request your token using `get-token`
To use the `get-token` script to get your tokens, use the script without the `--refresh` option. For example:
```
@@ -315,7 +315,7 @@ xxxxxxxxxx
##### Expires In Seconds ##########
86400
```
-### Refresh the Token Using `get-token`
+### Refresh the token using `get-token`
To use the `get-token` script to refresh your token, use the script with the `--refresh ` option. For example:
```
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/01_postgres_access.mdx b/product_docs/docs/edbcloud/beta/using_cluster/01_postgres_access.mdx
index f5717a3ba05..85c414e34df 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/01_postgres_access.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/01_postgres_access.mdx
@@ -1,5 +1,5 @@
---
-title: "Managing Postgres Access"
+title: "Managing Postgres access"
---
The `edb_admin` database role and `edb_admin` database created during the _Create Cluster_ process should not be used by your application. Instead, create a new database role and a new database, which provides a high level of isolation in Postgres. If multiple applications are using the same cluster, each database can also contain multiple schemas, essentially a namespace in the database. If strict isolation is needed, use a dedicated cluster or dedicated database. If that strict isolation level is not required, a single database can be deployed with multiple schemas. Please refer to the [Privileges](https://www.postgresql.org/docs/current/ddl-priv.html) topic in the PostgreSQL documentation to further customize ownership and roles to your requirements.
@@ -9,7 +9,7 @@ To create a new role and database, first connect using `psql`:
```
psql -W "postgres://edb_admin@xxxxxxxxx.xxxxx.edbcloud.io:5432/edb_admin?sslmode=require"
```
-## Notes on the edb_admin Role
+## Notes on the edb_admin role
The `edb_admin` role does not have superuser priviledges by default. You should contact [Support](../overview/06_support) to request superuser priviledges for `edb_admin`.
@@ -20,7 +20,7 @@ Don't use the `edb_admin` user or the `edb_admin` database in your applications.
EDB Cloud stores all database-level authentication securely and directly in PostgreSQL. The `edb_admin` user password is SCRAM-SHA-256 hashed prior to storage. This hash, even if compromised, cannot be replayed by an attacker to gain access to the system.
-## One Database with One Application
+## One database with one application
For one database hosting a single application, replacing app1 with your preferred user name:
@@ -41,7 +41,7 @@ For one database hosting a single application, replacing app1 with your preferre
Using this example, the username and database in your connection string would be `app1`.
-## One Database with Multiple Schemas
+## One database with multiple schemas
If a single database is used to host multiple schemas, create a database owner and then roles and schemas for each application. The example in the following steps shows creating two database roles and two schemas. The default `search_path` for database roles in EDB Cloud is `"$user",public`. If the role name and schema match, then objects in that schema will match first, and no `search_path` changes or fully qualifying of objects are needed. The [PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH) covers the schema search path in detail.
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/02_connect_to_cluster.mdx b/product_docs/docs/edbcloud/beta/using_cluster/02_connect_to_cluster.mdx
index 32bc705bf8f..32ea1a3fb9d 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/02_connect_to_cluster.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/02_connect_to_cluster.mdx
@@ -1,8 +1,8 @@
---
-title: "Connecting to Your Cluster"
+title: "Connecting to your cluster"
---
-You can connect to your cluster using [`psql`](http://postgresguide.com/utilities/psql.html), the terminal-based client for Postgres, or another client. See [Recommended Settings for SSL Mode](#recommended-settings-for-ssl-mode) for EDB's recommendations for secure connections.
+You can connect to your cluster using [`psql`](http://postgresguide.com/utilities/psql.html), the terminal-based client for Postgres, or another client. See [Recommended settings for SSL mode](#recommended-settings-for-ssl-mode) for EDB's recommendations for secure connections.
## Using `psql`
To connect to your cluster using `psql`:
@@ -14,7 +14,7 @@ To connect to your cluster using `psql`:
4. On the **Overview** tab, select the copy icon to the right of the **Quick Connect** field to copy the command for connecting to your cluster using `psql` to your clipboard. `psql` will prompt for the edb_admin user password you selected at cluster creation time.
5. Paste the command in your terminal.
-## Using Another Client
+## Using another client
To connect to your cluster using a client other than `psql`:
1. Sign in to the [EDB Cloud](https://portal.edbcloud.com) portal.
@@ -23,7 +23,7 @@ To connect to your cluster using a client other than `psql`:
2. Select the name of your cluster.
3. Select the **Connect** tab. You can review and copy all the relevant information you need from this screen except for the edb_admin user password. Please consult the client driver documentation for the connection string format the driver uses.
-## Recommended Settings for SSL Mode
+## Recommended settings for SSL mode
Different clients can have different default TLS/SSL modes (sslmode). For example, `psql` defaults to `prefer`, which means the client will attempt to establish a TLS connection but fall back to non-TLS if the server does not support it. In the `psql` example provided by EDB in the **Quick Connect** field, `sslmode` is explicitly set to `require`, which means the client will attempt a TLS connection and fail if the connection to the server can't be encrypted.
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/05_db_configuration_parameters.mdx b/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/05_db_configuration_parameters.mdx
index f9d9457de4f..b280604d1ec 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/05_db_configuration_parameters.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/05_db_configuration_parameters.mdx
@@ -1,5 +1,5 @@
---
-title: Modifying Database Configuration Parameters
+title: Modifying database configuration parameters
---
The database parameters listed on the DB Configuration tab are also referred to as Grand Unified Configuration (GUC) variables. See [What Is a GUC Variable?](https://www.enterprisedb.com/blog/what-guc-variable) for more information.
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/index.mdx b/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/index.mdx
index f90c03b0f72..29752e31f71 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/index.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/03_modifying_your_cluster/index.mdx
@@ -1,5 +1,5 @@
---
-title: Modifying Your Cluster
+title: Modifying your cluster
# Added this redirect because we removed the Modify and Scale topic
redirects:
- ../03_modify_and_scale_cluster
@@ -14,10 +14,10 @@ redirects:
| Settings | Tab |
| ------- | ----------- |
- | Cluster name and password | [Cluster Info](../../getting_started/03_create_cluster/#cluster_info) |
- | Instance type (vCPUs and memory)* | [Operational Settings](../../getting_started/03_create_cluster/#operational_settings) |
- | Networking type (public or private) | [Operational Settings](../../getting_started/03_create_cluster/#operational_settings) |
- | Database configuration parameters | [Database Configuration Parameters](05_db_configuration_parameters)
+ | Cluster name and password | [Cluster info](../../getting_started/03_create_cluster/#cluster_info) |
+ | Instance type (vCPUs and memory)* | [Operational settings](../../getting_started/03_create_cluster/#operational_settings) |
+ | Networking type (public or private) | [Operational settings](../../getting_started/03_create_cluster/#operational_settings) |
+ | Database configuration parameters | [Database configuration parameters](05_db_configuration_parameters)
| High availability (on or off) | [Availability](../../getting_started/03_create_cluster/#availability) |
*Changing the instance type could incur higher cloud infrastructure charges.
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/04_backup_and_restore.mdx b/product_docs/docs/edbcloud/beta/using_cluster/04_backup_and_restore.mdx
index 5dc96faff17..079498cd5be 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/04_backup_and_restore.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/04_backup_and_restore.mdx
@@ -1,5 +1,5 @@
---
-title: "Backing Up and Restoring"
+title: "Backing up and restoring"
---
### Backups
@@ -16,7 +16,7 @@ Cluster restores are not performed "in-place" on an existing cluster. Instead, a
You can restore backups into a new cluster in the same region.
-#### Performing a Cluster Restore
+#### Performing a cluster restore
1. Select the cluster you wish to restore on the [**Clusters**](https://portal.edbcloud.com/clusters) page in the [EDB Cloud](https://portal.edbcloud.com) portal.
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/05_monitoring_and_logging.mdx b/product_docs/docs/edbcloud/beta/using_cluster/05_monitoring_and_logging.mdx
index 006f41a0562..bd46bbe05f1 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/05_monitoring_and_logging.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/05_monitoring_and_logging.mdx
@@ -1,18 +1,18 @@
---
-title: "Monitoring and Logging"
+title: "Monitoring and logging"
---
EDB Cloud sends all metrics and logs from PostgreSQL clusters to Azure. This topic describes what metrics and logs are sent and how to view them.
-### Azure Log Analytics
+### Azure log analytics
When EDB Cloud deploys workloads on Azure, the logs from the PostgreSQL clusters are forwarded to the Azure Log Workspace.
To query EDB Cloud logs, you must use [Azure Log Analytics](https://docs.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-overview) and [Kusto Query language](https://azure-training.com/azure-data-science/the-kusto-query-language/).
-### Querying PostgreSQL Cluster Logs
+### Querying PostgreSQL cluster logs
All logs from your PostgreSQL clusters are stored in the _Customer Log Analytics workspace_. To find your _Customer Log Analytics workspace_:
@@ -31,7 +31,7 @@ All logs from your PostgreSQL clusters are stored in the _Customer Log Analytics
The following tables are available in the _Customer Log Analytic workspace_.
-| Table Name | Description | Logger |
+| Table name | Description | Logger |
| ---------- | ----------- | ------ |
| PostgresLogs_CL | Logs of the Customer clusters databases (all postgres related logs) | `logger = postgres` |
| PostgresAuditLogs_CL | Audit Logs of the Customer clusters databases | `logger = pgaudit or edb_audit` |
@@ -54,7 +54,7 @@ PostgresAuditLogs_CL
| sort by record_log_time_s desc
```
-### Using Shared Dashboards to View PostgreSQL Cluster Logs
+### Using shared dashboards to view PostgreSQL cluster logs
To view logs from your PostgreSQL clusters using Shared Dashboard:
@@ -66,6 +66,6 @@ To view logs from your PostgreSQL clusters using Shared Dashboard:
3. Select the resource of type _Shared Dashboard_ with the suffix -customer.
-4. Select the link _Go to dashboard_ located at the top of the page.
+4. Select the **Go to dashboard** link located at the top of the page.
diff --git a/product_docs/docs/edbcloud/beta/using_cluster/index.mdx b/product_docs/docs/edbcloud/beta/using_cluster/index.mdx
index ae379c26dd1..2454948ba59 100644
--- a/product_docs/docs/edbcloud/beta/using_cluster/index.mdx
+++ b/product_docs/docs/edbcloud/beta/using_cluster/index.mdx
@@ -1,5 +1,5 @@
---
-title: "Using Your Cluster"
+title: "Using your cluster"
---
In this section, account owners and contributors can learn how to connect, edit, scale, and monitor clusters through the EDB Cloud portal. This section also provides information on how EDB Cloud handles backup and restore.
diff --git a/scripts/fileProcessor/processors/cnp/update-yaml-links.mjs b/scripts/fileProcessor/processors/cnp/update-yaml-links.mjs
index 319f44af33f..8f5eb6fdc33 100644
--- a/scripts/fileProcessor/processors/cnp/update-yaml-links.mjs
+++ b/scripts/fileProcessor/processors/cnp/update-yaml-links.mjs
@@ -1,18 +1,45 @@
-export const process = (filename, content) => {
- const newContent = content.split("\n").map(rewriteLink).join("\n");
+import toVFile from "to-vfile";
+import remarkParse from "remark-parse";
+import mdx from "remark-mdx";
+import unified from "unified";
+import remarkFrontmatter from "remark-frontmatter";
+import remarkStringify from "remark-stringify";
+import admonitions from "remark-admonitions";
+import visit from "unist-util-visit";
+import isAbsoluteUrl from "is-absolute-url";
+
+export const process = async (filename, content) => {
+
+ const processor = unified()
+ .use(remarkParse)
+ .use(remarkStringify, { emphasis: "*", bullet: "-", fences: true })
+ .use(admonitions, {
+ tag: "!!!", icons: "none", infima: true, customTypes: {
+ seealso: "note", hint: "tip", interactive: "interactive",
+ }
+ })
+ .use(remarkFrontmatter)
+ .use(mdx)
+ .use(linkRewriter);
+
+ const output = await processor.process(toVFile({ path: filename, contents: content }));
return {
newFilename: filename,
- newContent,
+ newContent: output.contents.toString(),
};
};
-const rewriteLink = (line) => {
- const regex = /\[.+\]\((.+)\.yaml\)/;
- const match = line.match(regex);
- if (match === null) {
- return line;
- }
+function linkRewriter() {
+ return (tree) => {
- return line.replace(match[1], match[1].replace("samples/", "../samples/"));
-};
+ // link rewriter:
+ // - only links to .yaml files in samples dir
+ // - make relative to parent (because gatsby URL paths are always directories)
+ visit(tree, "link", (node) => {
+ if (isAbsoluteUrl(node.url) || node.url[0] === '/') return;
+ if (!node.url.includes(".yaml")) return;
+ node.url = node.url.replace(/^(?:\.\/)?samples\//, "../samples/");
+ });
+ };
+}
diff --git a/scripts/source/bdr.js b/scripts/source/bdr.js
index ccf198338f4..116f1629ec0 100644
--- a/scripts/source/bdr.js
+++ b/scripts/source/bdr.js
@@ -5,9 +5,9 @@
const path = require("path");
const fs = require("fs/promises");
const { read, write } = require("to-vfile");
-const remarkParse = require("@mdx-js/mdx/node_modules/remark-parse");
+const remarkParse = require("remark-parse");
const mdx = require("remark-mdx");
-const unified = require("@mdx-js/mdx/node_modules/unified");
+const unified = require("unified");
const remarkFrontmatter = require("remark-frontmatter");
const remarkStringify = require("remark-stringify");
const admonitions = require("remark-admonitions");
@@ -26,7 +26,11 @@ const imgPath = path.resolve("temp_bdr/docs/img/");
const processor = unified()
.use(remarkParse)
.use(remarkStringify, { emphasis: "*", bullet: "-", fences: true })
- .use(admonitions, { tag: "!!!", icons: "none", infima: true })
+ .use(admonitions, {
+ tag: "!!!", icons: "none", infima: true, customTypes: {
+ seealso: "note", hint: "tip", interactive: "interactive",
+ }
+ })
.use(remarkFrontmatter)
.use(mdx)
.use(bdrTransformer);