Replacing write servers

To replace the write server of a multiplex, you designate one of the query servers to become the new write server. While converting it, you must change the server name it uses. The new write server must have a server name that differs from any query servers already defined in the multiplex. You can use the former writer server’s name.

If the write server failed in such a way that its SYSTEM dbspace and transaction log files cannot be recovered, use the procedure “Replacing a write server that has no SYSTEM dbspace and/or transaction log file”. When the former write server's SYSTEM dbspace and transaction log files are available, use “Replacing a write server with intact files,”as follows:

StepsReplacing a write server with intact files

  1. Stop all the servers in the multiplex using Sybase Central. For details, see “Managing multiplex servers”.

  2. Use FTP or some other system facility to copy the write server's SYSTEM dbspace file(s) (dbname.db, typically, is the only one) to the new write server's directory

  3. Delete the transaction log file (dbname.log) in the new write server's directory and copy the transaction log file (dbname.log) from the old to the new write server.

  4. Using the dblog facility, ensure that the log file path is set correctly for the new write server. If you use transaction log mirroring, also check the setting for mirroring at the new write server.

  5. Start the query server that will become the write server in single-node mode, as follows:

    start_asiq @params.cfg -n <query-server> -iqmpx_sn 1 -iqmpx_ov 1 -x 'tcpip{port=<q-port>}' <db-file-name>
    
  6. Connect to the server as DBA and run the stored procedure:

    sp_iqmpxreplacewriteserver('new-write-server').
    
  7. Stop the server and restart it using the new write server name.

    start_asiq @params.cfg -n <new-write-server> -iqmpx_sn 1 -iqmpx_ov 1 -x 'tcpip{port=<q-port>}' <db-file-name>
    
  8. Connect as DBA and drop the old query server's dbspace definitions using:

    sp_iqmpxdropserverdbspaces('<query-server>')
    
  9. Stop the server.

  10. Start Sybase Central, then start the write server and synchronize all the query servers. If no query servers remain, synchronization is not required.

  11. If you use the administrative scripts that Sybase Central created, recreate them.

StepsReplacing a write server that has no SYSTEM dbspace and/or transaction log file

If a catastrophic loss of the write server occurs where the SYSTEM dbspace and transaction log files cannot be recovered, forced recovery is needed. Replace the write server as follows:

  1. Stop all the servers in the multiplex using Sybase Central. For details, see “Managing multiplex servers”.

  2. Choose the query server that was most recently synchronized (the one with the largest value in “DBA”.IQ_MPX_STATUS.catalog_version) to be the new write server. This preserves as much data as possible. Start this query server in single-node mode with the forced recovery and drop-leaks switches, as follows:

    start_asiq @params.cfg -n <query-server> -x 'tcpip{port=<w-port>}' -iqfrec <db-file-name> -iqdroplks <db-file-name> -iqmpx_sn 1 -iqmpx_ov 1 <db-file-name>
    
  3. Connect to the server as DBA and run the following stored procedure:

    sp_iqmpxreplacewriteserver('new-write-server')
    
  4. Recover free space in the IQ Store by running the command:

     sp_iqcheckdb('allocation database resetclocks')
    

    The execution time varies according to the size of the database, the number of tables or indexes specified, and the size of the machine.

  5. Stop the server.

  6. If you wish to enable log mirroring for the new write server or its log file, use the dblog utility.

  7. Restart the server using the new write server name:

    start_asiq @params.cfg -n <new-write-server> -x 'tcpip{port=<w-port>}' -iqmpx_sn 1 -iqmpx_ov 1 <db-file-name>
    
  8. Connect as DBA and drop the old query server's dbspace definitions using:

    sp_iqmpxdropserverdbspaces('<query-server>')
    
  9. Stop the server and start Sybase Central and synchronize all the query servers. If no query servers remain, synchronization is not required.

  10. If you use the administrative scripts that Sybase Central created, recreate them.