COMMANDDUMP – Upgrading from PHP 5.3 to 5.6 on Ubuntu 14.04

COMMANDDUMP – Upgrading from PHP 5.3 to 5.6 on Ubuntu 14.04

When upgrading from PHP version 5.3 to 5.6 there are several things to worry about.  On a shared system with multiple sites which do not make use of a common unit testing or library,  these tools and commands could be useful to find issues.  (this would also work from 5.4 or from 5.5 to 5.6)

COMMAND DUMP of things I ran.

Create a file call 5.4.php.searchterms

#echo import_request_variables >> upgrade.php.searchterms
#echo session_is_registered >> upgrade.php.searchterms
#echo session_register >> upgrade.php.searchterms
#echo session_unregister >> upgrade.php.searchterms
#echo define_syslog_variables >> upgrade.php.searchterms
#echo register_globals >> upgrade.php.searchterms
#echo sqlite >> upgrade.php.searchterms
#echo php_logo_guid >> upgrade.php.searchterms
#echo php_egg_logo_guid >> upgrade.php.searchterms
#echo php_real_logo_guid >> upgrade.php.searchterms
#echo zend_logo_guid >> upgrade.php.searchterms
#echo register_long_arrays >> upgrade.php.searchterms

#find -type f -name ‘*.php’ -exec grep -f upgrade.php.searchterms {} \; -ls

Check the version of your server

#lsb_release -a
#dpkg -l |grep php|grep apache
#php -v
#apache2ctl -vV

To upgrade from ubuntu 14.04 LTS you have to get php 5.6 from another repository as it is not includedin the default repos

apt-get -y update
apt-get install -y software-properties-common
add-apt-repository ppa:ondrej/php5-5.6 -y
apt-get -y update
apt-get -y install php5 php5-cli php5-common php5-curl php5-gd php5-imap php5-json php5-mysql php5-readline

You will be prompted when installing the latest version of PHP5 whether you want to keep the old or new version of PHP5.ini  I chosed to install the pakage maintainer’s version,   then I compare the two and update the new one with the differences.    The following command makes it easy to compare by removing all of the commented lines from the diff against the backed up file

cd /etc/php5/apache2
diff <(grep -v '^\s*;' php.ini|awk '$1 != ""') <(grep -v '^\s*;' php.ini.ucf-old|awk '$1 != ""')|more

I also updated the php.ini date.timezone setting to my area due to this php.net post

date.timezone = America/Boise

/etc/init.d/apache2 reload

Two step recipe – upgrading from Postgres 8.4 to 9.3 and then implementing 9.3 hot_standby replication

Two step recipe – upgrading from Postgres 8.4 to 9.3 and then implementing 9.3 hot_standby replication

Upgrade and existing postgresql database from Postgres 8.4 to 9.3 and then implementing a 9.3 hot_standby replication server so all backups and slow select queries can run from it.

The setup: two servers,   the current primary database server (will continue to be the primary database server when using 9.3,  but we will call it the master in the replication)
First get and install postgres 9.3 using the postgres apt repositories

master and standby> vi /etc/apt/sources.list
   - deb http://apt.postgresql.org/pub/repos/apt/ UNAME-pgdg main
#UNAME EXAMPLES: precise, squeeze, etch, etc
master and standby> apt-get update
master> apt-get install postgresql-9.3 postgresql-client-9.3 nfs-kernel-server nfs-client
standby> apt-get install postgresql-9.3 postgresql-client-9.3 postgresql-contrib-9.3 nfs-kernel-server nfs-client

Next create some shared directorys via nfs for file based archiving

standby> mkdir -p /data/dbsync/primaryarchive master> mkdir -p /data/dbsync-archiveto master> vi /etc/exports
   - /var/lib/postgresql/9.3/main 192.168.*.*(ro,sync,no_subtree_check,no_root_squash)
standby> vi /etc/exports
   - /data/dbsync/primaryarchive 192.168.*.*(rw,sync,no_subtree_che
master> vi /etc/fstab
   - SECONDARYSERVERIP:/data/dbsync/primaryarchive /data/dbsync-archiveto nfs ro 0 1
standby>mkdir -p /mnt/livedb
standby> mount PRIMARYSERVERIP:/var/lib/postgresql/8.4/main/ /mnt/livedb
master> mount /data/dbsync-archiveto

Now,  configure postgres on the master to allow replication and restart,   put it on port 5433 so there are no conflictw with 8.4

master> vi /etc/postgresql/9.3/main/pg_hba.conf - host replication all SECONDARYSERVERIP trust
master> vi /etc/postgresql/9.3/main/postgresql.conf
  - wal_level=hot_standby
  - archive_mode = on 
  - port = 5433
  - archive_command = 'test -f /data/dbsync-archiveto/archiveable && cp %p /data/dbsync-archiveto/%f'
master> /etc/init.d/postgresql restart

Configure postgres on the standby to allow it to run as a hot_standby

standby> vi /etc/postgresql/9.3/main/postgresql.conf
  -restore_command = a018/usr/lib/postgresql/9.3/bin/pg_standby -d -t /tmp/pgsql.trigger.5432 /data/dbsync/primaryarchive %f %p %r 2>>/var/log/postgresql/standby.log
  -recovery_end_command = a018rm -f /tmp/pgsql.trigger.5432
  - wal_level=hot_standby
  - hot_standby = on
standby> /etc/init.d/postgresql stop

 

Now lets get a base backup on the standby

standby> mv /var/lib/postgresql/9.3/main /var/lib/postgresql/9.3/main.old 
standby>cd /var/lib/postgres/9.3; mv main main.old; 
standby> pg_basebackup -D main -R -h192.168.120.201 -p5433 -x -Upostgres 
standby> chown postgres.postgres main/ -R
standby> /etc/init.d/postgres start

Thats it!!,  you should not have a working replication server

primary> create table tmp as select now();
secondary> select * from tmp;

#check the progress several ways. postregres log,  which files and recovery are running and by being able to connect and see updates from the master,  on the secondary

standby> tail /var/log/postgresql/postgresql-9.3-main.log
standby> grep 'database system is ready to accept read only connections'
standby> ps ax|grep post
 - postgres: wal receiver process streaming 3/43000000
master> psql -Upostgres -c 'select pg_switch_xlog()'
and the log file would switch in the recovery file
standby> ps ax|grep post
- postgres: startup process recovering 000000010000000300000037
That was all to make sure that the replication is working on 9.3,   now that I am comfortable with it working,  I am going to turn off the replication,  copy the data from 8.4 to 9.3 and recreate the replication
First lets stop the postgresql daemon on the standby server so the VERY heavy load from copying the db from 8.4 to 9.3 is not duplication
 
standby> /etc/init.d/postgresql stop

Next,  copy the database from 8.4 to 9.3,   I have heard there may be some problems for conversion of some objects between 8.4 and 9.3 but not for me,  this went great.

master> pg_dump -C -Upostgres mydatabase| psql -Upostgres -p5433

Once that is successful,   lets switch ports on the 9.3 and 8.4 servers so 9.3 can take over

master>vi /etc/postgresql/9.3/main/postgresql.conf
  - port = 5432
master>vi /etc/postgresql/8.4/main/postgresql.conf
  - port = 5433
master> /etc/init.d/postgres reload
Last step, get a base backup and start again.
standby> mv /var/lib/postgresql/9.3/main /var/lib/postgresql/9.3/main.old 
standby>cd /var/lib/postgres/9.3; mv main main.old; 
standby> pg_basebackup -D main -R -h192.168.120.201 -x -Upostgres 
standby> chown postgres.postgres main/ -R
standby> /etc/init.d/postgres start
standby> rm /var/lib/postgres/9.3/main.old* -rf

Now..... to figure out what to do with the archivedir method we are currently using.....  It seems that it is just building up  when do we use it?

Call Now Button(208) 344-1115

SIGN UP TO
GET OUR 
FREE
 APP BLUEPRINT

Join our email list

and get your free whitepaper