Register Today at http://www.openmakesoftware.com/devops-thought-leadership-webinar-series/

For more information on using OpenMake Release Engineer for Software Deployments, download the whitepaper “Why Choose Release Engineer” at:
http://www.openmakesoftware.com/docs/WhyChooseReleaseEngineer.pdf

1. Get the cluster id based on the cluster name.
2. Get the list of members for the cluster id.
3. Convert the list of members into a Jython array.

wsadminToList is found here.

1. Get a list the Servers that belong to the Cluster
2. Loop through the list of Servers in the Cluster
1. Stop the App on each server
3. Remove the App
4. Install the App
5. Apply warClassLoaderPolicy updates
6. Apply classLoader updates
7. Apply startingWeight
8. Loop through the list of Servers in the Cluster and apply the following if changed
1. Stop the Server
2. Apply genericJvmArguments
3. Apply initialHeapSize
4. Apply maximumHeapSize
5. Apply customProperty
6. Apply websphereVariables
7. Start the Server
9. Loop through the list of Servers in the Cluster
1. Start the Server if needed
2. Start the App on the Server if needed

TIPS:
The stopping and re-starting of the Server is only needed if genericJvmArguments, initialHeapSize, maximumHeapSize, customProperty, websphereVariables values have changed. Otherwise, the servers can be left running saving total deployment time.

Make sure to check if something is stopped or started prior to stopping or starting it, this will prevent errors from being thrown.

sudo docker run -it postgres:9.3 /bin/bash

will start the Container with the image named ‘postgres:9.3’ and put the user into a bash shell which will interact with the Container, but the database will not start. Only the bash shell will run, and this prevents any automatic startup of the database. The solution is to start the Container without any commands on the end:

sudo docker run -it postgres:9.3 # Starts the Container using the postgres:9.3 image. The database is automatically started.

then start another PuTTY (or whatever command line tool you prefer) window, and enter the already running Container via a shell:

sudo docker ps # get the id of the Container

sudo docker exec -it /bin/bash # enter the running container through the bash shell

Now you’re in the container via a bash shell, so you can use psql to manipulate the database

su – postgres # only the postgres user can run psql. Other databases may differ.

psql # this puts you into the psql client, and the command prompt will look like

postgres=#

Now you can manipulate the database via SQL and DDL commands.

cells = AdminConfig.list("Cell" )
cells = wsadminToList(cells)
cellName = cells[0].split('(')[0]

AdminConfig.list will return all defined cells. Typically people just use one cell. wsadminToList will create an array of cells. We take the first one from the array and then pull the name from the details.

wsadminToList is found here.

1. On Master – In pgAdmin run:

CREATE USER replicator REPLICATION LOGIN ENCRYPTED PASSWORD 'mypassword';

2. On Master – In pgAdmin, edit the postgresql.conf and set the following:

wal_level = hot_standby

max_wal_senders = 3

checkpoint_segments = 8

wal_keep_segments = 8

3. On Master – In pgAdmin, edit the pg_hba.conf and set the following where 5.6.7.8 is the ip address of the slave:

host replication     replicator     5.6.7.8/32           trust

4. On Master – restart the postgres windows service

5. On Slave – stop the postgres windows service

6. On Slave – open a command prompt and cd to your Postgres directory (c:\program files\Postgresql\9.4) and run:

rd /s “c:\program files\Postgresql\9.4\data”

7. On Slave – open a command prompt and cd to your Postgres directory (c:\program files\Postgresql\9.4) and run where 1.2.3.4 is the ip of the Master:

pg_basebackup -h 1.2.3.4 -D “c:\program files\Postgresql\9.4\data” -U replicator -v –P –X stream

8. On slave – In pgAdmin, edit the postgresql.conf and set the following:

hot_standby = on

9. On slave – create a text file (c:\program files\Postgresql\9.4\data\recovery.conf) with the following contents where 1.2.3.4 is the ip of the Master:

standby_mode = 'on'primary_conninfo = 'host=1.2.3.4 port=5432 user=replicator password=mypassword'trigger_file = 'c:\temp\postgresql.trigger'

10. On Slave – start the postgres windows service

Master and Slave should now be in sync. Update Master DB and confirm that the Slave is updated as well.