ENFOQUE PLAN DE FORMACIÓN PARA EL PROFESORADO DE LOS GRUPOS ARA EN
2.3 LOS GRUPOS ARA EN LA UP
This parameter has had an interesting history. It was originally introduced with HDR and then removed in some of the IDS V9 releases. However, it was restored starting with Version 10, which may surprise some administrators.
The intent of the parameter is a noble one in that it determines what action the secondary instance should take in the event of a replication failure. Depending on how this parameter is set, in a failure the secondary can perform one of the following actions:
0 (OFF): Remain in read-only mode until manually switched to standard or primary mode.
1 (RETAIN_TYPE): Automatically switch to primary mode, process
transactions from users, and then revert back to secondary mode when the original primary returns. As part of the change back to secondary, it will transfer its transaction records to the primary so they are logically consistent.
2 (REVERSE_TYPE): Automatically switch to primary mode and process
transactions. When the original primary returns, the original primary converts to secondary mode and receives transaction information from the new primary so both are logically consistent.
An issue with this parameter is that it assumes the only failure conditions that will occur are actual hardware failures on the primary, which takes it out of service. While this type of failure is certainly possible, it is far more common for
network-oriented issues to arise and cause a replication failure. In this case, having the secondary do anything other than remain in read-only mode will cause data integrity problems that can lead to the loss of some data.
When communication between the two instances is interrupted, both instances think the other has failed, and with DRAUTO set to either RETAIN® or REVERSE type, the secondary will switch to processing transactions. When communication is re-established with the original primary, depending on what DRAUTO is set to, the original primary may be told to convert to secondary, which it will not allow, or the secondary will try to push transactions to the original primary, which it will not receive. The only solution is to shut down the secondary and re-initialize HDR again. Any transactions processed on the secondary while it could support the full range of SQL operations will be lost, which could have a significant business impact.
For this reason, it is
STRONGLY
recommended that DRAUTO only be set to 0 (off) unless the business can absolutely guarantee the network connections will never fail under any circumstances.Handling a failover situation with DRAUTO set to 0 is not difficult and does not even require a trained IDS administrator to resolve. When a failure condition is declared, it is trapped by the ALARMPROGRAM. Depending on the business needs, anyone can be alerted to the condition. They can then log into a simple Web-based interface that asks a couple of basic Yes or No questions such as: Is the primary server offline?
Is there a network outage between the primary and secondary instances? Are all users blocked from accessing the primary instance but they can
access the secondary instance?
Will the primary instance be unavailable for longer than N minutes? (where N is replaced by the maximum allowable downtime)?
Depending on what questions are asked and the resulting answers, the script running behind the interface can convert the secondary into primary mode or leave it in read-only mode if the outage will not be very long.
3.3.2 DRINTERVAL
DRINTERVAL specifies the maximum number of seconds between flushes of the HDR data buffers.
HDR has two main modes of operation:
Synchronous
Asynchronous
To understand the difference, it will be helpful to be aware of how updates propagate from the primary to the secondary. Updates made to the primary server are replicated on the secondary server by having the primary server send all its logical-log records to the secondary server as the logs are generated.
When the primary database server starts to flush the contents of the logical-log buffer in shared memory to the logical log on disk, the database server also copies the contents of the logical-log buffer to a data-replication buffer on the primary database server. The primary database server then sends these logical-log records to the HDR secondary database server.
The HDR secondary database server receives the logical-log records from the primary database server into a shared-memory reception buffer (which the database server automatically adjusts to an appropriate size for the amount of data being sent). The secondary database server then applies the logical-log records through logical recovery.
The data replication buffers are part of the virtual shared memory that the primary database server manages. The data replication buffers hold logical-log records before the primary database server sends them to the HDR secondary database server. The data replication buffers are the same size as the logical-log buffers.
The primary database server sends the contents of the data replication buffer to an HDR secondary server either synchronously or asynchronously. The value of the ONCONFIG configuration parameter DRINTERVAL determines whether the database server uses synchronous or asynchronous updating.
Important: Because HDR depends on interrogating the logical logs, for HDR
HDR synchronous updating
When DRINTERVAL is set to -1, data replication to the HDR secondary server occurs synchronously. As soon as the primary database server writes the logical-log buffer contents to the HDR buffer, it sends those records from the buffer to the HDR secondary database server. The logical-log buffer flush on the primary database server completes only after the primary database server receives acknowledgment from the HDR secondary database server that the records were received.
HDR asynchronous updating
If you set DRINTERVAL to any value other than -1, data replication occurs asynchronously to the HDR secondary server. The primary database server flushes the logical-log buffer after it copies the logical-log buffer contents to the HDR buffer. Independent of that action, the primary database server sends the contents of the HDR buffer across the network when one of the following conditions occurs:
The HDR buffer becomes full.
The time interval specified by DRINTERVAL on the HDR primary has elapsed since the last time that the HDR replication buffers have been flushed.
3.3.3 DRTIMEOUT
The DRTIMEOUT configuration parameter specifies the interval for which either database server waits for a transfer acknowledgment from the other. If the primary database server does not receive the expected acknowledgment, it adds the transaction information to the file named in the DRLOSTFOUND
configuration parameter. If the secondary database server receives no acknowledgment, it changes the data-replication mode as the DRAUTO configuration parameter specifies.
The following formula explains the formula that the engine uses to detect a timeout:
DRTIMEOUT = wait_time / 4
In this formula, wait_time is the length of time, in seconds, that a database server in a high-availability data-replication pair must wait before it assumes that a high-availability data-replication failure occurred.
For example, suppose you determine that wait_time for your system is 160 seconds. Use the preceding formula to set DRTIMEOUT as follows:
Detection of HDR failure
The database server interprets either of the following conditions as an HDR failure:
The specified timeout value was exceeded. During normal HDR operation, a database server expects confirmation of communication from the other database server in the pair. Each database server in the pair has an
ONCONFIG parameter, DRTIMEOUT, that specifies a number of seconds. If confirmation from the other database server in a pair does not return within the number of seconds that DRTIMEOUT specifies, the database server assumes that an HDR failure has occurred.
The other database server in the primary-secondary pair does not respond to the periodic messaging (pinging) attempts over the network. The database servers ping each other regardless of whether the primary database server sends any records to the secondary database server. If one database server of a primary-secondary pair does not respond to four sequential ping
attempts, the other database server assumes that an HDR failure has occurred.
Each database server in the pair sends a ping to the other database server in the pair when the number of seconds specified by the DRTIMEOUT
parameter on that database server has passed.
Checkpoints
A checkpoint on the primary database server completes only after it completes on the secondary database server. If the checkpoint does not complete within the time that the DRTIMEOUT configuration parameter specifies, the primary database server assumes that a failure has occurred
3.3.4 DRLOSTFOUND
DRLOSTFOUND specifies the path name to the dr.lostfound.timestamp file. This file contains transactions committed on the primary database server but not committed on the secondary database server when the primary database server experiences a failure. The file is created with a time stamp appended to the file name so that the database server does not overwrite another lost-and-found file if one already exists.
This parameter is not applicable if updating between the primary and secondary database servers occurs synchronously (that is, if DRINTERVAL is set to -1).
Lost-and-Found transactions
With asynchronous updating, a transaction committed on the primary database server might not be replicated on the secondary database server. This situation can result if a failure occurs after the primary database server copies a commit record to the HDR buffer but before the primary database server sends that commit record to the secondary database server.
If the secondary database server is changed to a standard database server after a failure of the primary database server, it rolls back any open transactions. These transactions include any that were committed on the primary database server but for which the secondary database server did not receive a commit record. As a result, transactions are committed on the primary database server but not on the secondary database server. When you restart data replication after the failure, the database server places all the logical-log records from the lost transactions in a file (which the DRLOSTFOUND configuration parameter specifies) during logical recovery of the primary database server. Figure 3-3 illustrates the process.
If the lost-and-found file appears on the computer that is running the primary database server after it restarts data replication, a transaction has been lost. The database server cannot reapply the transaction records in the lost-and-found file because conflicting updates might have occurred while the secondary database server was acting as a standard database server.
To reduce the risk of a lost transaction without running data replication in synchronous mode, use unbuffered logging for all the databases. This method reduces the amount of time between the writing and transfer of the transaction records from the primary database server to the secondary database server.
3.3.5 DRIDXAUTO
Specifies whether the primary High-Availability Data Replication (HDR) server automatically starts index replication if the secondary HDR server detects a corrupted index. To enable automatic index replication, set the value of the DRIDXAUTO configuration parameter to 1.
Replicating an index to the secondary server
If an index on an HDR secondary database server becomes corrupt and needs to be rebuilt, either of the following actions can be taken:
Manually replicate the index from the primary server to the secondary server. Let the secondary server automatically replicate the index if DRIDXAUTO is
enabled.
If this functionality is enabled, when one of the threads on the secondary database server detects a corrupt index, the index is automatically replicated to the secondary database server. Restarting index replication can take up to the amount of time specified in seconds in the DRTIMEOUT configuration parameter. Sometimes it may be desirable to replicate an index manually, for example, when index repair must be postponed because the table is locked. To be able to manually replicate an index on the HDR secondary server, turn off the automatic replication feature.
Note: You can alter the value of DRIDXAUTO for a running server instance
without restarting the instance by using the onmode -d idxauto command. However, the onmode -d idxauto command will not change the value of the DRIDXAUTO parameter in the ONCONFIG file.
To turn off the automatic index replication feature, either: Set onmode -d idxauto to off.
Set the DRIDXAUTO configuration parameter to 0.
If onmode -d idxauto is set to off or DRIDXAUTO is set to 0 and the secondary server detects a corrupt index, you can manually replicate an index on the HDR secondary server by issuing an onmode -d index command in the following format:
onmode -d index database:[ownername].table#index Example 3-1 shows a specific sample of the command usage.
Example 3-1 Onmode -d index to resend an index to the secondary onmode -d index cash_db:user_dx.table_12#index_z
In the case of a fragmented index with one corrupt fragment, the onmode -d idxauto option only transfers the single affected fragment, whereas the onmode -d index option transfers the whole index.
The online.log file produced by the secondary server contains information about any replicated index.
3.3.6 LOG_INDEX_BUILDS
With IDS 11, there is a new algorithm (Index Page Logging) to handle the transfer of log pages from the primary to the secondary server. This new method affects the availability of the server during the transfer of the index pages. Index Page Logging can be turned on by setting the LOG_INDEX_BUILDS parameter to 1. It can be enabled dynamically by running onmode -wf LOG_INDEX_BUILDS=1.
When Index Page Logging is activated, the primary sends the index to the HDR secondary through the logs and does not perform the current index transfer. The algorithm transfers the index pages to the secondary while creating the index rather than simply having the secondary build the index locally. This is because the secondary is a read-only server.
However, there are certain requirements for an index build to complete successfully:
The HDR secondary must be available during the transfer of the index pages. The index is not immediately usable even on the primary until all index pages have been successfully transferred to the secondary and put in their proper place.
The new functionality of Index Page Logging minimizes this lag:
Index pages are copied to the logical log when initially creating the index. The logging of the index can be broken into multiple transactions and is not
tied to the original user transaction.
Control of the index is returned as soon as logging is performed.
For more information about Index Page Logging, please refer to 5.1.3, “Index Page Logging” on page 96.
3.3.7 ENCRYPT_HDR
ENCRYPT_HDR enables or disables HDR encryption. Enabling HDR encryption provides a secure method for transferring data from one server to another in an HDR pair. HDR encryption works in conjunction with Enterprise Replication (ER) encryption. However, it is not necessary to have ER encryption enabled for HDR encryption. HDR encryption works whether or not ER encryption is enabled. HDR and ER share the same encryption configuration parameters:
ENCRYPT_CIPHERS, ENCRYPT_MAC, ENCRYPT_MACFILE, and ENCRYPT_SWITCH.
For more on these encryption parameters, please refer to section 2.2.3, “Encrypted communication” on page 33.
3.3.8 OFF_RECVRY_THREADS
OFF_RECVRY_THREADS specifies how many logrecvr threads are started on the secondary. Starting more logrecvr threads on the secondary can improve performance.
3.4 Setting up HDR
Here are the general steps for instantiating an HDR pair.
On the primary
1. Edit the HDR configuration parameters (DRAUTO, DRTIMEOUT, DRINTERVAL, DRLOSTFOUND, DRIDXAUTO and, optionally, LOG_INDEX_BUILDS) in the $ONCONFIG file.
2. Add entries to the $INFORMIXSQLHOSTS and /etc/services files for network connections.
3. Modify the /etc/hosts.equiv or the .rhosts file for the informix user ID to enable trusted communication.
4. Make sure the databases to be replicated are in logged mode.
5. Send a copy of the primary instance’s $ONCONFIG file to the secondary server.
6. Make a level 0 archive.
7. Run onmode -d primary secondary_server.
On the secondary
1. Add entries to the $INFORMIXSQLHOSTS and /etc/services files for network connections.
2. Modify the /etc/hosts.equiv or the .rhosts file for the informix user ID to enable trusted communication.
3. Modify the ONCONFIG parameters for the secondary server: DBSERVERNAME and DBSERVERALIASES
4. Make sure that all chunk paths are created, have the correct permissions, and ensure that there is enough space on the disks for the data to reside.
5. Do a physical restore of the physical archive.
6. If necessary, run onmode -l to roll forward any logical logs that may have been saved on the primary before the secondary’s physical restore finished. 7. Run onmode -d secondary primary_server.