In this post I’ll explain how to run a WordPress site using Azure services for managed MySQL and App Services for a PHP application.
The basic offerings for MySQL and App Services create these resources in a public subnet, so in order to integrate them with your VNETs, you’ll have to use the more expensive options. In this post, we’ll use just that. We’ll create the MySQL database without any public access and integrate the App Services to connect to the SQL database internally.

VNET/subnets

First, we’ll create a VNET with three subnets. When you integrate an App Services in a VNET, the subnet where the App Services will reside must be empty. The same applies for Flex MySQL servers. You can have multiple Apps in the same dedicated subnet. So, you need a dedicated subnet for both App Service and MySQL Flex, but not for MySQL single server. Single MySQL server can share the subnet with other resources.
For MySQL, there are two options. We can use a private endpoint or a VNET integration. We’ll go with a private endpoint first. We don’t need a dedicated subnet for this.
In my case, I’ll create a VNET with 192.168.100.0/22 CIDR and three subnets, 192.168.100.0/24 for some Infra/MySQL stuff, 192.168.101.0/24 for the App Services and 192.168.102.0/24 for Flex MySQL. I’ll use a new resource group called rgWordPress. The VNET will be called vnetWordPress and the subnets, subInfra, subApp and subMySQL respectively.

VM

I will also create a VM in the subInfra subnet. This VM is not needed at all, it will be used to test connectivity. In my case, I’ll spin a new Debian 1CPU, 1GB VM and I’ll install the MySQL client.

sudo apt install default-mysql-client

Managed Single server MySQL

When it comes to MySQL, there are two options: Flexible server and Single server. Look at this link to determine what you want to use. In most of the cases, you’ll use a Flexible server. But there are some limitations in both use cases. For example, a Flexible server can’t use private endpoints. You are limited to VNET integration and Single server can’t be VNET integrated. On top of that, only General Purpose and Memory Optimized servers can have private endpoints. The basic single server can be public only. Flex VNET integrated servers require dedicated and empty subnets. There are other limitations as well, so take a look at the link above.
In my case, I am using a General Purpose server.

Once you create the server, it will be public. As you can see from the Overview for the server, there is a public DNS record.

On the left side/blade, under Security, click on Private endpoint connections and create one.
Name the private link and put it in the same resource group as the other resources.

For the resource type Microsoft.DBforMySQL/servers and you’ll be able to select the newly created MySQL server from the dropdown under Resource.

Finally, choose the virtual network and subnet where you want to put the private link. Do not use the subnet for App Services. In addition, make sure that the integration with the private DNS zone is set to Yes.

If you log to the server that we just built and try to resolve the public DNS for the MySQL server, you’ll see that it resolves as a private IP. That’s because you have a private DNZ zone that takes precedence over the public DNS.

In case, you are still getting the public IP, go to the Private DNS zone and make sure that it’s linked to the actual VNET.

Now you can try to connect to the MySQL database.

mysql -u klimenta@mysqlwordpress-single -h mysqlwordpress-single.mysql.database.azure.com -p

Where -u specifies the username and the -h is the host. These parameters are under Overview on the right side. See the screenshot above.
You might get the following error. ERROR 9002 (28000): SSL connection is required. Please specify SSL options and retry.
In that case, download the SSL certificate and try again.

wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
mysql -u klimenta@mysqlwordpress-single -h mysqlwordpress-single.mysql.database.azure.com -p --ssl-ca=BaltimoreCyberTrustRoot.crt.pem

In case you are wondering, wait, why this cert? – The answer is here.
As you can see, I am able to connect now.

It is also recommended to disable the public access. Go to Connection security under Settings and select Yes for Deny public network access.

App Services

Go to App Services and create one. Make sure you use Premium offering so you can do a VNET integration. The initial parameters are self explaining. Use the defaults for the rest of the screens. You won’t be able to do much with PHP anyway.

Once the app is provisioned, on the left side/blade, go to the Networking menu under Settings. You’ll see that the VNET integration is not configured. Click on the link.

Pretty much, you have to select the VNET and an empty subnet. As you can see, I can only select subApp from the dropdown.

Close the blade and from the App menu, click on SSH under Development Tools on the left. This will open a new tab in your browser with a SSH session.

We have to create the WordPress database now. You can do that from the test server that we used initially or from the actual SSH session. Let’s use the SSH session. It already comes with mysql client preinstalled.

wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
mysql -u klimenta@mysqlwordpress-single -h mysqlwordpress-single.mysql.database.azure.com -p --ssl-ca=BaltimoreCyberTrustRoot.crt.pem

Once in MySQL client, execute these SQL statements.

CREATE DATABASE dbwordpress;
GRANT ALL PRIVILEGES ON dbwordpress.* TO "wordpressuser"@"%" IDENTIFIED BY "SuperSecret";
FLUSH PRIVILEGES;
EXIT

Replace the values with yours for the database name, MySQL host name, username and password.
Now, you can download WordPress and extract it.

cd /home/site/wwwroot
wget -c http://WordPress.org/latest.tar.gz
tar -xzvf latest.tar.gz
mv WordPress/* /home/site/wwwroot/
rm -rf WordPress
rm -rf latest.tar.gz

Once completed, go to the URL for the app. It should be under the Overview. You have to provide the database name (dbwordpress), username (wordpressuser@mysqlwordpress-single), password (SuperSecret) and the database host (mysqlwordpress-single.mysql.database.azure.com).
Most likely you’ll see an error. The easiest way is to disable the SSL requirement for the MySQL database from Connection security under Settings for the database.

If this doesn’t work for you, you’ll have to manually specify the parameters in wp-config.php. You can search this on your own.
Once you are done, specify the values in WordPress install screen and you are all set.

Flex MySQL server

Let’s see how Flex MySQL server works. Go to Azure MySQL but this time provision a flex server.
This is how my setup looks like.

…and this.

A flexible MySQL server can’t have a private endpoint, but it can be VNET integrated, same as the Azure App Services. And if you choose for the flex server to be VNET integrated, you’ll need a dedicated and empty subnet, same as Azure App Services.

Once you provision the flex MySQL server, you’ll be able to manage it the same as a single server with a private endpoint. You can also see the entry in the private DNS zone for a flex server, same as with the single server. A flex server also allows you to have a hot standby HA pair but you can’t use this hot standby as a replica. A HA will double the price and you won’t be able to create replicas. The HA is in a different zone but in a same region and it allows forced and automatic failovers. And if you want to use a read only replica (up to 10), you have to take care of the SQL proxying using ProxySQL, HAProxy or Nginx.
So, if you want some sort of HA for the MySQL, go with the flexible MySQL. You’ll have automatic failover within the region. But if you want to recover from a regional failure, use a single MySQL server with a read replica in another region (flexible MySQL can’t have replica in another region) and when you need to failover, just promote the replica in a standalone server (you’ll also need an Azure App Service in the DR region). The bad thing is that once you promote a replica in a standalone server and the original regions comes back up, you can’t revert the DR MySQL server in a replica again.

In this article, I’ll explain how to install and configure two Windows 2019 servers running MS SQL 2017 Enterprise with AlwaysOn. The servers will have local storage only but you’ll still have HA. There are several prerequisites that you need in order to test this scenario.

– Functional AD and rights to create objects in AD
– Unrestricted traffic access between the SQL nodes and AD (you can probably restrict the ports, but do your research)
– Two AD accounts (an user account and a SQL service account)
– Two extra IPs assigned to each SQL node
– Proper DNS resolution in AWS and time synced between the nodes and DCs

Domain controllers and AD

I have two DCs running in two zones in the same region. Make sure that you can ping/resolve the servers by using only the short DNS name. E.g. My first domain controller is dc01. When I do ping dc02 from dc01, it resolves fine. If not, check the DNS settings. You should also check the advanced DNS settings. Make sure that your domain is on the top. In my case, I have the DNS settings of dc01 pointing to itself and dc02. Notice ad-domain.local on top of other suffixes. AD-DOMAIN.LOCAL is the name of my domain. If you have the DNS suffixes configured on the VPC level, you don’t have to make this change. The only thing important is that you have a proper DNS resolution.

Open up AD Users and Computers (dsa.msc) and create a single service account for the SQL servers. I’ll call it svc_sql and it should be a member of Domain Users only. The password should never expire. This account will run the SQL DB engine on SQL nodes.
Then create an OU for the cluster object. In my case, I’ll create an OU called SQLCLUSTERS.

Then create the name of your SQL cluster as a computer object and disable it.

In AD Users and Computers, under the View menu, make sure that Advanced Features is enabled. Right-click the SQL cluster computer object and choose Properties, then click on Security tab and click Add. Type the name of the service account you just created and give it Full Control.

We also need the cluster computer account to have rights to the OU. Right-click the OU that you just created, choose Properties and under the Security tab, click Advanced.
You’ll see something like this.

Click Add and in the new dialog that shows up, in the upper left corner, click the link Select a principal.

By default, computer object are not going to show up, so click on Object Types button, then check Computer and click OK to go back to the screen above.
Type the name of the SQL cluster and click on Check Names to verify it.

Click OK when it reminds you that the object is disabled. In the Permission Entry dialog box, make sure that the Type is set to Allow, and the Applies to is set to This object and all descendant objects. Finally, under Permissions, click on the Create Computer objects check box. Click OK until you close all open dialogs.

The AD part is now complete.

WSFC (Windows Server Failover Cluster)

Now, we have to create and configure the failover cluster. I have two SQL nodes, node01 and node02. We have to install WSFC on each node, but before doing that, let’s add extra two IPs per node. In AWS console, on each SQL instance, click on the network adapter, usually called eth0.

Click on the Interface ID.

Then from the Actions drop down, click on Manage IP Addresses.

Add two extra IPs per instance. You can choose DHCP provided IPs or manual. I decided to go with manual assignment. Make sure the IPs are in the same subnet as the primary and they are not in use.

For node01, I’ll use 192.168.1.60 and 192.168.1.61 and for node02 I’ll use 192.168.2.60 and 192.168.2.61. node01 and dc01 are in a 192.168.1.0/24 subnet and node02 and dc02 are in 192.168.2.0/24 subnet. Now, log to both nodes with an admin account and add the SQL service account svc_sql as a local administrator. Then log off and log back to SQL nodes as svc_sql service account.
On both nodes, install the WSFC (Windows Server Failover Cluster) from an elevated PowerShell prompt and reboot.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Once the instances come back, log as svc_sql and create the cluster. Open up an elevated command or PowerShell prompt and type cluadmin.msc (do this on one node, not both). In the wizard dialog box, click Browse and type the name of the nodes.

The cluster wizard will do some pre-checks and if everything looks good click Next.

Do not skip this part. Make sure you validate the cluster and you run all tests. It takes about a minute or two.

You’ll see some warnings about the network, but you can ignore them. This is how my report looked like. You’ll be able to enter the name of the cluster if everything is OK. In my case, the cluster name is the disabled computer object SQLCLUSTER01 that we created earlier.

Make sure you uncheck the storage setting. We are using local storage, so there is nothing to add to the cluster as a resource.

After a minute, you should get a greeting that the cluster is OK.

Back in the cluster manager, you’ll see this mess. Don’t worry.

At the bottom of the cluster manager, right click the first node and choose Properties.

How do you know which one is which? Once you open the properties, look at the Network under the General tab. Based on the subnet, you’ll have to assign the IP that belongs to that subnet. So, in my case this is how it looked like before I made the change.

I know that 192.168.2.0/24 belongs to node02, so I’ve changed the settings from DHCP to Static IP and added 192.168.2.60. Remember this IP? It was the first one that we added to node02. Scroll up if you forgot.

Do the same for the 2nd entry. This time you have to add 192.168.1.60 because the subnet is 192.168.1.0/24. Then, bring the cluster online.

Now, you can install the SQL server.

SQL Server installation

As I mentioned earlier, make sure you have correct DNS settings and the time is in sync with AD. Before you install MS SQL, make sure you have your partitions ready. They don’t have to be like this, you can use C:\ only for everything, but ask your DBA how they want to carve the space for the DB. I am using the trial version downloaded from here.

Run the installation on both nodes using the service account svc_sql. You made this a local admin, didn’t you? Click on Installation on the left side and the first option for a new SQL Server stand-alone…

Choose license.

Accept the license terms and use or do not use Microsoft Update for SQL updates.
Ignore the warning for the firewall.

Check the Database Engine Service, SQL Server Replication…

…scroll down and check Client Tools Connectivity.

Click on Named instance and type your name. In my case it’s SQL2017.

Leave the Service Accounts as is. We’ll change one of them later.

Under Server Configuration tab, use Windows authentication mode and click Add Current User.

On the Data Directories tab in the same dialog you can change the disk destinations. If you have just one C:\ partition you can skip this part. If not, map the directories here. Here are mine.

And for TempDB on the next tab in the same dialog.

Proceed to Install until the installation completes successfully.

SQL Management Tools (optional)

This step is optional. If you have SSMS already installed, you can skip this part. If not, install it on a node, both or any client workstation. From the same setup menu, install SQL Management Tools (third from the top). This will take you to a MS web site where you can download the latest SMSS (SQL Server Management Studio).

SQL service account change

Before you reboot, let’s change the account that runs SQL. This is mandatory for a SQL cluster. DO NOT change the account from the Services console, instead open SQL 2017 Configuration Manager.
Do this on both nodes. Select where it says SQL Server Services on the left and then right-click on SQL Server (SQL2017) on the right and choose Properties.
Enter the SQL service account, its password and click Apply. This will reset the SQL service and change it to run under the domain service account. Do not reboot yet.

Dynamic ports and firewall

Because we are using a named SQL instance, the DB engine assigns a random dynamic port for the listener. Instead of opening a range of ports on the firewall, we can restrict the listener to a static port and then open the firewall for that port only. Do this on both nodes. In the same SQL 2017 Configuration Manager, look for SQL Server Network Configuration on the left, expand it and select Protocols for SQL2017 or whatever you named your instance. Right-click where it says TCP/IP on the right and choose Properties.

Click on the second tab IP Addresses and scroll all the way down where it says TCP Dynamic Ports. Delete that value, leave it blank and in the next field TCP Port below, enter a random TCP port from 49152-65535. I’ll use 50000 for both nodes. You need to restart the SQL service for this change to take effect, but we’ll reboot, so no need for that. But, if you have your Windows Firewall enabled, you have to open these TCP ports. Run these command from an elevated PowerShell prompt.

New-NetFirewallRule -Name "SQL2017 Named Instance (in)" -Description "SQL2017 Named Instance" `
-DisplayName "SQL2017 Named Instance" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 50000
New-NetFirewallRule -Name "SQL Server Rule (in)" -Description "SQL Server Rule" `
-DisplayName "SQL Rule" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 1433
New-NetFirewallRule -Name "SQL Server Browser Rule (in)" -Description "SQL Server Browser Rule" `
-DisplayName "SQL Browser Rule" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol UDP -LocalPort 1434
New-NetFirewallRule -Name "SQL Server AlwaysOn Replication (in)" -Description "SQL Server AlwaysOn Replication" `
-DisplayName "SQL Server AlwaysOn Replication" -Enabled:True -Profile Domain,Public,Private `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 5022

Now, you can reboot.

AlwaysOn

Log as the SQL service account svc_sql and open SQL Configuration Manager. You have to do this on both nodes. Similarly to what you did when you change the SQL service account, do the same.

Select SQL Server Services, right-click SQL Server (SQL2017) and check Enable AlwaysOn Availability Groups under AlwaysOn High Availability tab.

Restart the SQL service on both nodes. Once completed, open SSMS, connect to a node and create a new database.

I’ll name my database MyDB.

Make sure you backup the database. You can’t proceed without this step.

Little further below, right-click on Always On High Availability and click on New Availability Group Wizard.

Specify a name for the availability group.

Select the database that we just created.

Click on Add Replica.

Connect to node02.

I want automatic failover which means it’s a synchronous commit.

Choose Automatic Seeding.

Don’t worry about the listener.

After 10-20 seconds the configuration should complete.
Now, we need to add a listener. Expand the Availability Groups, right-click Availability Group Listeners and select Add Listener.

Give listener a name (in my case MyListener), you can choose a port (I used the default 1433, you can choose a random port but don’t forget to open the firewall) and add the other two IPs as static IPs.

Right-click the availability group and click on Show Dashboard.

Everything should be with green checkmarks and both states should be synchronized. The availability group (and the database) are configured for automatic failover, but you can do manual failover if you want. Right-click the availability group and click on Failover. This is how my manual failover looks like.

At this point you have a fully functional AlwaysOn cluster.

Test the failover (optional)

We’ll use a sample populated table to run some queries from PowerShell. Then, we’ll stop one node and watch the outcome. In order to do the test, open up SMSS, log as svc_sql and connect to the listener directly.

Click on New Query from the top.

Insert these statements. They’ll create a SQL login mapped from the domain name (in my case klimenta) and a table in the MyDB database called COLORS. Replace the values that match your domain name and the database. Execute the first part (CREATE LOGIN) on node02 too.

CREATE LOGIN [AD-DOMAIN\klimenta]  
    FROM WINDOWS  
    WITH DEFAULT_DATABASE = [MyDB];
USE MyDB;
CREATE TABLE COLORS (ID INT, NAME VARCHAR(10));
INSERT INTO COLORS VALUES(1,'RED');
INSERT INTO COLORS VALUES(2,'YELLOW');
INSERT INTO COLORS VALUES(3,'BLUE');
INSERT INTO COLORS VALUES(4,'WHITE');
GO

Double-click the login that you just created, click on User Mapping and put a checkmark next to MyDB database.

Right-click the database, choose Properties then click on Permissions. Select the username and make sure you have Connect and Select permissions.

From a separate workstation/server, you can use even the domain controller, log as the username (klimenta) that you just granted right to the MyDB database. Open up PowerShell ISE and run this script. Replace the values for the listener and the database. It’s a script that connects to the database and spits the contect of the COLORS table indefinitely. Use CTRL-C to break.

$Server = 'tcp:mylistener,1433'    
$database = 'MyDB'
$Connection = New-Object System.Data.SQLClient.SQLConnection
$Connection.ConnectionString = "server=$($Server);database=$($Database);trusted_connection=true;MultiSubnetFailover=True;"
$Connection.Open()
$Command = New-Object System.Data.SQLClient.SQLCommand
$Command.Connection = $Connection
$x=0
while ($true) {
    $Command.CommandText = 'SELECT * FROM COLORS'
    $Reader = $Command.ExecuteReader()
    $Datatable = New-Object System.Data.DataTable
    $Datatable.Load($Reader)
    $Datatable
    Start-Sleep -s 5
    Write-Host($x, "---")
    $x++;
}
$Connection.Close()  

Once you see the output, shutdown the primary node or do a manual failover. You’ll notice that there is no interruption in the program flow. The only thing that changes is the IP of the listener.

Links

YouTube (AWS)
Microsoft
PowerShell

If you’ve installed BitBucket on a CentOS 7 server and use PostgreSQL as the back-end database, you’ve probably seen this nagging warning that support for PostgreSQL 9.2.24 has been deprecated and will be removed in an upcoming release.

While PostgeSQL 9.2 is quite old and they are already announcing version 12, mind that any of the Atlassian stack can’t support anything more than version 9.6 at the time of this writing.
So, I’ll explain how to upgrade PostgreSQL on CentOS from 9.2.24 to PostgreSQL 9.6. While this post is for CentOS, it might work for other distros too. There are some prerequisites though. First, I assume that you installed PostgreSQL using yum from the default repo. In this case, your database most likely resides under /var/lib/pgsql/data and the binaries are under /usr/bin/psql. If you use the default version, then you probably use systemctl start/stop postgresql to manage the start/stop of the database daemon. If you have something different, the following tutorial will probably work, but you’ll have to adjust some directories.
First thing first, let’s check the version of PostgreSQL that we use.

psql --version
psql (PostgreSQL) 9.2.24

Next, stop any services that use the database, such as BitBucket, Jira or Confluence or whatever you have there.
Log as the postgres user that you use to manage the database. By the default this user is postgres.
Do a full backup and move the backup somewhere because the home directory for the postgres user is where the database home is. You can compress the SQL file first. It’s just a plain text file.

pg_dumpall > backup.sql
mv backup.sql somewhere/

Once done, stop the postgreSQL daemon, but log as root first. You won’t be able to stop the daemon using the postgres user.

systemctl stop postgresql

Go to a temp folder and get the RPM package from the PostgreSQL site. In case the link doesn’t work, go to the website using a browser and see what’s the latest 9.6 version.

cd /tmp
wget https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6-3.noarch.rpm

Install the newer version.

rpm -ivh pgdg-centos96-9.6-3.noarch.rpm
yum install postgresql96-server

You’ll get some warning that symlinks can’t be created but you can ignore them. The new version installs the binaries under /usr/psql-9.6/bin.
Log as the postgres user and initialize the new database.

/usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data/
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/pgsql/9.6/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /usr/pgsql-9.6/bin/pg_ctl -D /var/lib/pgsql/9.6/data/ -l logfile start

Ignore the line that says that we can start the server. We have to upgrade the current database first. Make sure that the directories below are the same as yours. If not, make changes.

/usr/pgsql-9.6/bin/pg_upgrade --old-datadir /var/lib/pgsql/data/ --new-datadir /var/lib/pgsql/9.6/data/ --old-bindir /usr/bin/ --new-bindir /usr/pgsql-9.6/bin/
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok

*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

connection to database failed: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/lib/pgsql/.s.PGSQL.50432"?


could not connect to old postmaster started with the command:
"/usr/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data/" -o "-p 50432 -b  -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start
Failure, exiting

Oh boy. If you check the error message, you’ll get some more info.

tail /var/lib/pgsql/pg_upgrade_server.log
server stopped


command: "/usr/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data/" -o "-p 50432 -b  -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start >> "pg_upgrade_server.log" 2>&1
waiting for server to start....FATAL:  unrecognized configuration parameter "unix_socket_directory"
 stopped waiting
pg_ctl: could not start server
Examine the log output.

The reason being that as of PostgreSQL version 9.3 the config parameter unix_socket_directory has been replaced with unix_socket_directories. There is a workaround thanks to this guy. The link for more info is here.
Pretty much, all you have to do is execute these lines first. Execute these lines as root or sudo user.

mv /usr/bin/pg_ctl{,-orig}
echo '#!/bin/bash' > /usr/bin/pg_ctl
echo '"$0"-orig "${@/unix_socket_directory/unix_socket_directories}"' >> /usr/bin/pg_ctl
chmod +x /usr/bin/pg_ctl

Now you can do the upgrade.

/usr/pgsql-9.6/bin/pg_upgrade --old-datadir /var/lib/pgsql/data/ --new-datadir /var/lib/pgsql/9.6/data/ --old-bindir /usr/bin/ --new-bindir /usr/pgsql-9.6/bin/
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* system OID user data types                ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for roles starting with 'pg_'                      ok
Checking for invalid "line" user columns                    ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows on the new cluster                        ok
Deleting files from new pg_clog                             ok
Copying old pg_clog to new server                           ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Setting oldest multixact ID on new cluster                  ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster
                                                            ok
Setting minmxid counter in new cluster                      ok
Copying user relation files
                                                            ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

Start the new database now and check everything. As you can see, the startup script is different. This time we have to specify the version of PostgreSQL. As root do:

systemctl start postgresql-9.6

You can revert the change back.

mv -f /usr/bin/pg_ctl{-orig,}

Log as postgres user and do a check up. It might take some time if your database is large.

./analyze_new_cluster.sh

You can delete the old database if you want.

./delete_old_cluster.sh

If you check the new version, you’ll see that it’s the same.

psql --version
psql (PostgreSQL) 9.2.24

The database is upgraded and running 9.6, it’s just the psql binary that’s the old version. You have to tell the postgres user to use the new binaries. Delete the old binaries first, uninstall the old version, make sure it doesn’t start on boot and enable the new version. Also, if you have any specific configurations, make sure you compare postgresql.conf and pg_hba.conf under /var/lib/pgsql/data and /var/lib/pgsql/9.6/data. Log as root first. Make sure it says 9.2 when you run yum remove.

systemctl disable postgresql
yum remove postgresql

Enable postgreSQL to boot on start.

systemctl enable postgresql-9.6

Add the following line under .bash_profile for the postgres user.

export PATH=$PATH:/usr/pgsql-9.6/bin

If you don’t have a .bash_profile file, check if there is any .bash_profile.rpmsave. Rename this one as .bash_profile and add the above line. It should look like this.

[ -f /etc/profile ] && source /etc/profile
PGDATA=/var/lib/pgsql/9.6/data
export PGDATA
# If you want to customize your settings,
# Use the file below. This is not overridden
# by the RPMS.
[ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile
export PATH=$PATH:/usr/pgsql-9.6/bin

If you log off, log back on as the postgres user or execute source .bash_profile and check the version, you’ll see that you are all set.

psql --version
psql (PostgreSQL) 9.6.11

I had to migrate a SQL 2014 database from our on-prem environment to AWS. The requirement was to use RDS. So, these are the steps that I’ve taken in order to successfully migrate the database. You can also check the official AWS link here.

First, take a backup of the existing database in BAK format. In my case for the purpose of this blog, I’ve backed up my vCenter database called VCDB in a file called VCDB.BAK. Once you have the file, create a S3 bucket in AWS with the default settings and upload the BAK file there. In my case the S3 bucket was named restoremybackup.
Next, make sure you have access to a Windows server with SQL Management Studio installed, either in AWS or on-prem, but this server will need to talk to the RDS database over port 1433 TCP. I built a server in AWS and installed the SQL Management Studio, which is a free download. Make sure that you have a security group in place that allows port 1433. We will use this security group to assign it to the RDS instance. I’ve created a new security group called sgAllowSQLAccess. For the source, type the IP of the server with SQL Management Studio or the security group itself.

Then, go to RDS and create an Option Group. Name the Option Group, in my case it’s ogSQL2014Restore, choose the engine and the version. I am using sqlserver-se which is SQL Standard Edition and the version is 12.00 which is MS SQL 2014.

Once created, select your Option Group and click on Add Option.

Choose SQLSERVER_BACKUP_RESTORE, then click on Create a New Role. For the role, use a name, in my case it’s iamRestoreSQLBackup. Then type the name of the S3 bucket that you just created and make sure that you select Apply Immediately – yes.
Then click on Add Option.

Now, it’s time to create the RDS database. Launch a new RDS instance and use the parameters that suit your needs.

For the next set of options, choose your preferred settings, but make sure that you assign the Security Group that we just created and the Option Group that we also created. In my case it looks like this.

Once the RDS it’s in available state, try to telnet to port 1433 to the RDS endpoint from the Windows server where you have the SQL Management Studio installed. If everything is OK, you are ready to restore the database. In SQL Management Studio, select a New Query and type the following.

exec msdb.dbo.rds_restore_database 
        @restore_db_name='database_name', 
        @s3_arn_to_restore_from='arn:aws:s3:::bucket_name/file_name_and_extension';

Replace ‘database_name’ and ‘bucket_name/file_name_and_extenstion’ with your values. In my case, they were VCDB and restoremybackup/VCDB.BAK.

In this post I’ll describe how I installed vCenter 5.0 on Windows 2008 R2 server using SQL 2008 R2 database. I’ve used two servers in my lab, one for the vCenter and the other one for the SQL. I won’t explain how to install SQL server, it’s fairly straightforward.

First thing to do is to create the SQL database. VMware provides a SQL script that you can execute to create the database. The script is on the vCenter installation DVD/ISO under source\vCenter-Server\dbschema folder where source is some drive letter (D:\ or E:\). This script does not work right, so we’ll use a modified version. By default, vCenter requires full db_owner rights so it can create some scheduled jobs. If your environment doesn’t allow this type of access, see the installation guide for vCenter. In this post, we’ll grant full db_owner rights for the sql user (vpxuser) to both vCenter database (VCDB) and the msdb system database. Once vCenter is up and running, you can remove the full db_owner rights from the msdb.

Start the SQL Server Management Studio, log as the sa user or some domain user with full SQL admin rights, and click New Query.

Copy and paste the following script, but change the file path where you want your database to reside. In my case it is C:\DATA. Also, change the password for the vpxuser that we will create.

use [master]
go
CREATE DATABASE [VCDB] ON PRIMARY
(NAME = N'vcdb', FILENAME = N'C:\DATA\VCDB.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcdb_log', FILENAME = N'C:\DATA\VCDB.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCDB
go
sp_addlogin @loginame=[vpxuser], @passwd=N'vpxuserpassword', @defdb='VCDB',
@deflanguage='us_english'
go
ALTER LOGIN [vpxuser] WITH CHECK_POLICY = OFF
go
CREATE USER [vpxuser] for LOGIN [vpxuser]
go

While in SQL Server Management Studio, expand the Security, then Logins. Double-click on the vpxuser and choose User Mapping. Select the VCDB database and put a check mark for db_owner. Put a check mark on the msdb database and do the same (check mark on db_owner).

Next thing to do is to install the SQL Server Native Client on the vCenter server. It’s a free download from Microsoft. Once installed, go to Administrative Tools | Data Sources (ODBC). Click on System DSN tab and then click Add. You should see a SQL Server Native Client 10.0 driver there. Do not use SQL Server driver. It won’t work.

Enter the name for the ODBC connection, a description and type the hostname for the SQL server. In my case, I’ll use vCenter, vCenter Database and sql.

Next, choose SQL authentication and type the SQL user that we just created with the script (vpxuser and its password).

Click the first check mark and select the VCDB database.

Leave the defaults and click Finish.

Click the Test Data Source button and make sure that it says that the connection completed successfully.

Now, it’s time to install vCenter. Insert the DVD or mount the ISO image and the installer will start.

Click the first option vCenter server and go thru the Next, Accept cycle. Once you reach the Database Options, select the second radio button and choose the ODBC connection that we just created.

If you get this error, make sure you start the SQL Server Agent on the SQL server. By default this service is disabled. You can stop this service once the installation completes.

Enter the SQL username and password that we just created.

If you receive the following error, it means that you are not a db_owner on the VCDB database.

You won’t be able to continue until you fix this. When you reach this screen vCenter Server Service, stop. You have an option to run the vCenter Server service as a local server account or you can choose a domain account. If you use a domain account, it should be a local admin on the server.

Change or accept the defaults for the vCenter program.

Select the first option.

Change or accept the default ports. If you install vCenter on a shared server with IIS installed, you’ll have port conflicts here.

Change or accept the default ports for the Inventory Service.

Estimate how many VMs you’ll have.

Click Install.

After couple of minutes, click Finish to complete the install. Your vCenter Server should be up and running, but we are not over yet.

We will install the Update Manager now. This part of vCenter is used to patch the vCenter and ESXi hosts. Log back to the SQL server and in SQL Server Management Studio, execute this script that will create a new database for the Update Manager. Make sure you change the file path for the database. In my case is C:\DATA. We’ll use the same vpxuser user for the Update Manager database.

CREATE DATABASE [VCUM] ON PRIMARY
(NAME = N'vcum', FILENAME = N'C:\DATA\VCUM.mdf', SIZE = 2000KB, FILEGROWTH = 10% )
LOG ON
(NAME = N'vcum_log', FILENAME = N'C:\DATA\VCUM.ldf', SIZE = 1000KB, FILEGROWTH = 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
go
use VCUM
go

On vCenter server, go to C:\Windows\SysWOW64 folder and run odbcacd32.exe. The Update Manager is using a 32-bit ODBC and by default, if you go to Administrative Tools and start the ODBC manager, you’ll execute the 64-bit version.

Pick a name and description for this ODBC connection and specify your SQL server hostname.

Select the VCUM database that we just created and similarly to the previous ODBC creation, finish the rest of the steps.

Start the Update Manager install.

Accept the defaults.

Create a domain user that will run the Update Manager service. In my case I use svc_vcenter.

Specify the 32-bit ODBC connection that we just created.

Enter the same vpxuser and password.

Specify if any proxy servers need to be specified. Update Manager requires Internet connection.

Change or accept the defaults.

The rest of the steps a re just plain Next, Next, Finish.

Once installed, go back and install the vCenter client. I won’t explain how to do this. It’s trivial. Log to the vCenter with a local admin password or with a domain account (if you run vCenter service under a domain account).

Select the top left vCenter server name and then click on Permissions.

Click Add.

Type your domain, enter a user that you want to grant full admin rights and click Check Names. If everything is OK, the dialog box will just blink.

Back in the previous dialog, select Administrator and click OK. We made svc_vcenter an admin vCenter user.

From the vCenter client menu, select Plug-Ins and select the Update Manager plug-in.

Click Run.

Create a new datacenter, add the ESXi hosts and you are all set.