Ever since VMware released our new version of the popular PostgreSQL, we have been working hard to publish a series of informative articles on what’s new in the vFabric Postgres (vPostgres) 9.2 release. There are a number of cool things like major performance and scale improvements, elastic memory for vPostgres, contributions to open source, master-slave clusters, and new GUI capabilities. In this post, we are going to dig into some tips and tricks for internal use of a vFabric Postgres virtual machine, talk about scripts, and explain the management of the network interface.
First, to see what we are talking about, it would be helpful to login to your vFabric Postgres VM. vPostgres supports SSL by default (see last weeks post on securing your vPostgres deployment for more security tips). Therefore, it is pretty easy to connect to a server and set things up inside for those who really want to personalize things at a very low level (like
pg_bha.conf for connection restrictions). After the first initialization, you can connect either as user postgres or root with the same password you used at first boot.
As with every other system, it is never really recommended to connect with the user root for security reasons. By connecting with user postgres you will find the following things once connected.
postgres@localhost:~> ls -l
drwxr-xr-x 2 postgres users 4096 Jan 10 13:21 bin
As vFabric Postgres is designed to be a portable PostgreSQL backend, the default user environment is not set up with PATH to allow someone to easily find the binaries or data inside the virtual machine.
Now that you’re in, let’s take a look at what tips we can give you for performing operations on the internals of the virtual machine.
Embedded vPostgres Server Internals
You can find the PostgreSQL latest binaries in
/opt/vmware/vpostgres/current/bin. In order to use PostgreSQL binaries internally, I recommend launching the following command:
echo "export PATH=$PATH:/opt/vmware/vpostgres/current/bin >> $HOME/.bashrc"
This will update the environment variable PATH to automatically find Postgres-related binaries located in the given folder. As this path is loaded at each new session, you will need to reconnect to the server to be able to use it.
As a normal PostgreSQL release, those commands are common front-end and back-end applications, like for example
psql/pg_dump/pg_restore for the client side, or
initdb/postgres/pg_ctl to manage the database server directly. With these commands, you can control of vFabric Postgres server at a very low-level.
Then, the data of the vPostgres instance runs inside the vFabric Postgres appliance available in folder
/var/vmware/vpostgres/current/pgdata. Like a common PostgreSQL 9.2 installation, you can find the following files.
PG_VERSION global pg_hba.conf pg_log pg_notify pg_snapshots pg_subtrans pg_twophase pgstartup.log postgresql.conf.auto postmaster.pid server.crt
base pg_clog pg_ident.conf pg_multixact pg_serial pg_stat_tmp pg_tblspc pg_xlog postgresql.conf postmaster.opts root.crt server.key
First you will notice that
server.key, which are used to set up the SSL connection of the server are different from a normal PostgreSQL installation. The reason is that the certificate is based on VMware’s certificate. Also, you will notice that
postgresql.conf is generated automatically for some parameters.
postgres@localhost:/var/vmware/vpostgres/current/pgdata> ls -l postgresql.conf*
lrwxrwxrwx 1 root root 57 Jan 22 04:32 postgresql.conf -> /var/vmware/vpostgres/current/pgdata/postgresql.conf.auto
-rw-r--r-- 1 postgres users 19994 Jan 22 04:32 postgresql.conf.auto
wal_buffers are updated automatically depending on the memory available inside the virtual machine, and
postgresql.conf is updated in consequence depending on any dynamic modifications. Also, ssl mode is enabled by default for security reasons.
As an expert on PostgreSQL, I suggest that database admins and data fabric managers keep a light, worry-free mind with regards to the settings of
postgresql.conf—let vFabric Postgres do the work for you. It will automatically find the best settings depending on your needs. Of course, feel free to ask questions or make comments below—solid technologists always want to have an understanding of what is being magically auto-optimized under the hood, and we’re happy to help.
vPostgres System-related Scripts
Here is more information about the system itself. System operations should only be performed by root. This is the default behavior by the way in vFabric Postgres.
All the critical system scripts are located in folder
One particularly useful utility is called
set_passwd. It allows you to kill three birds with one stone—you can reset the password for system users root and postgres to the same value at one time along with the database user postgres. In case you forget your database password, it’s a good idea to remember this folder. Here is how it works:
localhost:/opt/aurora/sbin # ./set_password
Updated root password
Updated postgres system password
Updated postgres database password
Type your new password two times and you are done.
vPostgres Network Management
Finally, here is a tip list concerning the management of the network interface of vFabric Postgres. All the network-related scripts are located in
/opt/vmware/share/vami. The only one you need to remember is
vami_config_net, which is a wrapper that controls all the NIC settings of your virtual machine.
localhost:/opt/vmware/share/vami # ./vami_config_net
0) Show Current Configuration (scroll with Shift-PgUp/PgDown)
1) Exit this program
2) Default Gateway
5) Proxy Server
6) IP Address Allocation for eth0
Be sure to use it if there are connectivity problems related to the IP settings of the appliance vFabric Postgres.
For More Information on vPostgres
- Read about the key performance and scale improvements in vFabric Postgres 9.2
- Learn about the dynamic memory management of vFabric Postgres
- Download the details of the new vFabric Reference Architecture
- Learn about some of the PostgreSQL open source contributions by the vFabric team
- Take vFabric Postgres for a test drive
- Get the product overview and find more resources
|About the Author: Michael Paquier is a member of PostgreSQL technical staff at VMware. He is involved for many years with community development of PostgreSQL and Postgres-XC, and has worked on multi-master database technologies. He has also interest in parallel query processing and concurrent SQL processing.|