You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: hugo/content/how-it-works/_index.adoc
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -396,19 +396,20 @@ See link:https://github.com/CrunchyData/crunchy-containers/blob/master/docs/exam
396
396
=== Manual Failover
397
397
398
398
With manual failover some key features include:
399
+
399
400
* when you perform a failover, a new replica is created to replace the
400
-
replica that was promoted to even out the cluster to the original
401
+
replica that was promoted to even out the cluster to the original
401
402
number of replicas
402
403
* when you perform a failover, the promoted replica is removed from the pgreplica CRD to represent the current *truth*
403
404
404
-
The *pgo failover --query* command will return a list of replica
405
+
The `pgo failover --query` command will return a list of replica
405
406
targets which you can select from. That list include the *Ready* status
406
407
of the database as well as the Kube node name it is running on.
407
408
408
409
=== Auto Failover
409
410
410
411
Starting with release 3.1, there is an *auto* failover mechanism
411
-
that can be leveraged by *pgo* users if enabled.
412
+
that can be leveraged by *pgo* users if enabled.
412
413
413
414
This feature will cause the operator to start a timer on a database
414
415
primary that has received a *NotReady* status after the database
@@ -420,7 +421,7 @@ back to a *Ready* status within that timer period, a failover
420
421
is triggered for this cluster. The failover target is selected
421
422
by the auto failover logic.
422
423
423
-
The amount of time (in seconds) the auto failover timer will wait before
424
+
The amount of time (in seconds) the auto failover timer will wait before
424
425
triggering a failover is determined by the following *pgo.yaml* setting:
425
426
....
426
427
AutofailSleepSeconds: 9
@@ -430,18 +431,19 @@ If the above setting is not configured a default value of 30 seconds is
430
431
chose.
431
432
432
433
The logic of auto failover works like this:
433
-
* the readiness probe on the primary database container is executed every few seonds to check the *readiness* of the database, this is what tells Kubernetes whether or not the container is *Ready* or *NotReady*.
434
+
435
+
* the readiness probe on the primary database container is executed every few seonds to check the *readiness* of the database, this is what tells Kubernetes whether or not the container is *Ready* or *NotReady*.
434
436
* if a *NotReady* state is detected then that event is caught by the operator which is watching for database containers created by the operator
435
437
* upon a *NotReady* event, a timer is started for that database which acts as the final check as to if a failover is required for that database
436
438
* if the timer expires and the state is still *Not Ready* then the manual
437
439
failover logic is executed for this cluster which causes a promotion of
438
-
a replica to primary, and also creates a replacement replica
440
+
a replica to primary, and also creates a replacement replica
439
441
* only replica targets with a status of *Ready* will be used to select
440
442
the target to promote
441
443
442
444
The readiness probe settings are defined in the following template:
Copy file name to clipboardExpand all lines: hugo/content/installation/manual-installation.adoc
+18-18Lines changed: 18 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,9 +10,20 @@ v3.0, {docdate}
10
10
11
11
== Project Structure
12
12
13
-
To perform an installation of the operator, first create the project structure as follows on your host, here we assume a local directory called *odev* -
13
+
First, define the following environment variables in *.bashrc*:
To perform an installation of the operator, first create the project structure as follows on your host, here we assume a local directory called *odev* -
To pull prebuilt versions from Dockerhub of the *postgres-operator* containers, specify the image versions, and execute the following Makefile target -
91
+
To pull prebuilt versions from Dockerhub of the *postgres-operator* containers, execute the following Makefile target -
84
92
....
85
-
export CO_IMAGE_PREFIX=crunchydata
86
-
export CO_IMAGE_TAG=centos7-3.0
87
93
make pull
88
94
....
89
95
@@ -136,22 +142,16 @@ This Operator is developed and tested on the following operating systems but is
136
142
* *CentOS 7*
137
143
* *RHEL 7*
138
144
139
-
First, install the project library dependencies. The godep dependency manager is used for this purpose. -
145
+
Before compiling the Operator, it's necessary to install the *Mercurial* requirement.
140
146
....
141
-
cd $COROOT
142
-
make setup
147
+
sudo yum -y install mercurial
143
148
....
144
149
145
-
Then, compile the PostgreSQL Operator using the Makefile.
150
+
Then, install the project library dependencies. The godep dependency manager is used for this purpose. Then, compile the PostgreSQL Operator using the Makefile and deploy the operator to your Kubernetes cluster.
146
151
....
147
152
cd $COROOT
153
+
make setup
148
154
make all
149
-
which pgo
150
-
....
151
-
152
-
Finally, deploy the operator to your Kubernetes cluster.
153
-
....
154
-
cd $COROOT
155
155
make deployoperator
156
156
....
157
157
@@ -160,7 +160,7 @@ make deployoperator
160
160
== Makefile Targets
161
161
162
162
The following table describes the Makefile targets -
0 commit comments