The fourth chapter of PostgreSQL replication set up asynchronous Replication (4)

4.4 Stream-based and file-based recovery

Life is not always black or white; sometimes there are some shades of gray. For some scenarios, stream replication may be just right. In other cases, file-based replication and PITR are what you need. However, there are also many cases where you need both stream replication and file-based replication. One example: When you interrupt replication for a longer period of time, you may want to use the archive again to resynchronize (resync) slave instead of performing a full base backup again. This may also be useful---keep an archive for a period of time after the investigation or replay operation. The good news is that PostgreSQL allows you to mix file-based and stream-based replication. You don't have to decide whether the flow-based good or file-based is good, you can use both ways to benefit. What should you do? In fact, you've seen all the steps; we just put them together in the right way.

To make this easier for you, we've written a complete example for you.

4.4.1 Master Configuration

On master, we use the following configuration in postgresql.conf:

Wal_level = Hot_standby

# Minimal, archive, or Hot_standby

# (change requires restart)

Archive_mode = On

# allows archiving to being done

# (change requires restart)

Archive_command = ' cp%p/archive/%f '

# command to archive a logfile segment

# placeholders:%p = path of file to archive

#%f = file name only

Max_wal_senders = 5

# We used five here some spare capacity

In addition, we have to add some configuration to the pg_hba.conf to allow the flow mechanism. Here is an example:

# Allow replication connections from localhost, by a user with the

# replication privilege.

Local Replication HS Trust

Host Replication HS 127.0.0.1/32 Trust

Host replication HS:: 1/128 Trust

Host replication All 192.168.0.0/16 MD5

In our case, we simply opened a complete network to allow replication (keep the example simple).

Once we have made these changes, we can restart Master and do a basic backup as we did earlier in this chapter.

4.4.2 Slave configuration

Once we have configured master and made a basic backup, we can start configuring our slave system. For the sake of simplicity, let's assume we're just using a slave; we're not cascading to other systems.

We just need to change the line in slave's postgresql.conf:

Hot_standby = on # to make the slave readable

Next, we can write a simple recovery.conf file and put it in the main data directory:

Restore_command = ' cp/archive/%f%p '

Standby_mode = On

Primary_conninfo = ' host=sample.postgresql-support.de port=5432 '

Trigger_file = '/tmp/start_me_up.txt '

When we start slave, the following things can happen:

1. PostgreSQL invokes the Restore_command command to fetch the transaction log from the archive.

2. The call to Restore_command is not stopped until there are no more log files in the archive.

3. PostgreSQL will attempt to establish a stream connection.

4. If the data exists it will perform a flow operation.

° If no data is stored, it will invoke the Restore_command command to fetch the transaction log from the archive.

° It will continue to do this until there is no more data in the archive.

° It will try to establish a stream connection again.

You can keep the flow operation as long as you need it. If you want to convert slave to master, you can use trigger_file defined in Pg_ctl promote or recovery.conf again.

4.4.3 Error Scenario

The most important advantage of a dual strategy is that you can create a cluster that provides a higher level of security than just a stream-based or simple file-based replay.

In this section, we can discuss some of the typical error scenarios in a dual strategy cluster.

Network connectivity between master and slave is interrupted

If the network fails, master may no longer be able to perform the Archive_command operation successfully. The history of the Xlog file must remain in place, so that master must queue those xlog files for later archiving. This can be a dangerous scenario, because if the file stream is permanently interrupted, you may run out of xlog space on master.

If the stream connection fails, PostgreSQL will attempt to keep itself synchronized through the file-based channel. If the file-based channel also fails, slave will stay there waiting for the network to connect back. Once the network comes back, it will try to get xlog and simply continue.

[Keep in mind that slave requires an uninterrupted xlog stream, and if no Xlog file is missing or if the stream connection still provides slave for slave xlog that needs to be manipulated, it can only continue to replay Xlog. ]

Restart slave

As long as the archive has xlog to do slave backup, restarting slave will have no harm, slave will only start again and try to get xlog from any available source. There will be no crashes or any other such problems.

Restart Master

If master restarts, there's nothing to criticize. The slave will be notified by the stream connection that master cannot be found. It will try to get xlog through two channels, but it will not succeed until Master comes back. There's no such thing as a crash or something bad happening. Restart two servers, the operation can be simply restored.

Corrupted Xlog in the archive

If the xlog is corrupted in the archive rollup, we want to differentiate between the two scenarios:

1. Slave is streaming: if the flow is fine and complete, slave will not notice that there are some xlog files in the archive that are damaged in some way. As long as the stream connection is available, slave never needs to be read from the Xlog file.

2. If we do not use a stream, but instead replay from a file, PostgreSQL will check each XLOG record and see if it is correctly verified. If any errors occur, slave will not continue to replay the corrupted Xlog. This will ensure that no other problems are derived and that no corrupted xlog are replayed. Your database may be incomplete, but it would be wise to have the same error point.

Of course, there are too many things going wrong, but given these similarities, you can clearly see that the design is as reliable as possible.

Original address: http://www.cnblogs.com/songyuejie/p/4743516.html

The fourth chapter of PostgreSQL replication set up asynchronous Replication (4)