postgresql database not replicating. No errors - linux

Question

Background:
I am trying to set up streaming replication between two servers. Although postgresql is running on both boxes without any errors, when I add or change a record from the primary, these changes are not reflected on the secondary server.
I have the following set up on my primary database server:
(Note: I'm using fake ip addresses but 10.222.22.12 represents the primary server and .21 the secondary)
primary server - posgresql.conf
listen_addresses = '10.222.22.12'
unix_socket_directory = '/tmp/postgresql'
wal_level = hot_standby
max_wal_senders = 5 # max number of walsender processes
# (change requires restart)
wal_keep_segments = 32 # in logfile segments, 16MB each; 0 disables
primary server - pg_hba.conf
host all all 10.222.22.21/32 trust
host replication postgres 10.222.22.0/32 trust
primary server - firewall
I've checked to make sure all incoming to the fw is open and that all traffic out is allowed.
secondary server - posgresql.conf
listen_addresses = '10.222.22.21'
wal_level = hot_standby
max_wal_senders = 5 # max number of walsender processes
# (change requires restart)
wal_keep_segments = 32 # in logfile segments, 16MB each; 0 disables
hot_standby = on
secondary server - pg_hba.conf
host all all 10.222.22.12/32 trust
host all all 10.222.22.21/32 trust
host replication postgres 10.222.22.0/24 trust
secondary server - recovery.conf
standby_mode='on'
primary_conninfo = 'host=10.222.22.12 port=5432 user=postgres'
secondary server firewall
everything is open here too.
What I've tried so far
Made a change in data on the primary. Nothing replicated over.
Checked the firewall settings on both servers.
Checked the arp table on the secondary box to make sure it can communicate with the primary.
checked the postmaster.log file on both servers. They are empty.
Checked the syslog file on both servers. no errors noticed.
restarted postgresql on both servers to make sure it starts without errors.
I'm not sure what else to check. If you have any suggestions, I'd appreciate it.
EDIT 1
I've checked the pg_stat_replication table on the master and I get the following results:
psql -U postgres testdb -h 10.222.22.12 -c "select * from pg_stat_replication;"
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | state | sent_location | write_location | flush_location | repl
ay_location | sync_priority | sync_state
-----+----------+---------+------------------+-------------+-----------------+-------------+---------------+-------+---------------+----------------+----------------+-----
------------+---------------+------------
(0 rows)
And on the slave, notice the results from the following query:
testdb=# select now()-pg_last_xact_replay_timestamp();
?column?
----------
(1 row)
openser=#

Answer 1

I changed the pg_hba.conf file on the primary and added the exact ip addr of my slave like so:
host all all 10.222.22.21/32 trust
host replication postgres 10.222.22.0/32 trust
#added the line below
host replication postgres 10.222.22.12/32 trust
Then I restarted postgresql and it worked.
I guess I was expecting that the line above the new line I added would work, but it's not. I have to do more reading on subnetting.

Answer 2

On master, listen address should allow connection from slave, i.e
listen_addresses = '10.222.22.21'
It seems your postgres logging not well configured.
My guess is, the slave cannot stream because it falls behind the master, it can be due to network latency.
My suggestion is, You should archive the wal files, so if the slave falls behind the master, it can replay wal files from the archive.
You can also check by doing
select * from pg_stat_replication;
on master. If it does not show any rows, it means that streaming fails, probably due to slave falls behind the master.
You can also check by issuing :
select now()-pg_last_xact_replay_timestamp();
on slave. The query count how far the slave falls behind the master.
Usually, streaming replication lag is under 1s. Lag larger than 1s, then streaming will be cut off.