Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 10.0.1 » SQL Anywhere Server - Database Administration » SQL Anywhere High Availability » Introduction to database mirroring

Tutorial: Using database mirroring Next Page

Setting up database mirroring


The following steps assume that one database server is already running the database for which you want to set up a mirroring system.

When starting database servers that will be participating in a mirroring system, it is recommended that you include the -su option to specify the password for the utility database. Then, you can use the utility database to shut down the server, or force the mirror server to become the primary server should such a need arise. See -su server option.

For information about upgrading SQL Anywhere or rebuilding a database involved in a database mirroring system, see Upgrading SQL Anywhere software and databases in a database mirroring system.

To set up a mirroring system
  1. Make a copy of the database and current transaction log on a second server.

    If the existing database server is stopped, you can copy files; otherwise, use the BACKUP DATABASE statement or the Backup utility (dbbackup). See BACKUP statement, and Backup utility (dbbackup).

  2. Stop the running database server and modify its command line configuration to include the mirroring options and then start the server.

    For example:

    dbsrv10 -n server1 -x tcpip(PORT=2638) -xf c:\server1\server1state.txt -su sql 
    c:\server1\mirrordemo.db -sn mirrordemo 
    -xp partner=(ENG=server2;LINKS=tcpip(PORT=2637;TIMEOUT=1));auth=abc;
    arbiter=(ENG=arbiter;LINKS=tcpip(PORT=2639;TIMEOUT=1));mode=page;autofailover=YES
  3. Start another operational server.

    For example:

    dbsrv10 -n server2 -x tcpip(port=2637) -xf c:\server2\server1state.txt -su sql 
    c:\server2\mirrordemo.db -sn mirrordemo 
    -xp partner=(ENG=server1;LINKS=tcpip(PORT=2638;TIMEOUT=1));auth=abc;
    arbiter=(ENG=arbiter;LINKS=tcpip(PORT=2639;TIMEOUT=1));mode=page;autofailover=YES
  4. Start the arbiter server.

    For example:

    dbsrv10 -x tcpip -n arbiter 
    -xa AUTH=abc;DBN=mirrordemo -xf arbiterstate.txt
    -su sql

    Clients can now connect to the mirrored database.

Connecting to a mirrored database server

When connecting to a mirrored database, clients must use the server name that was specified by the -sn option in the commands used to start the primary and mirror servers. Using the example above (database servers were started with the option -sn mirrordemo), clients specify the connection parameter ENG=mirrordemo in their connection string:

...UID=user12;PWD=x92H4pY;ENG=mirrordemo;LINKS=tcpip...

If the primary and mirror servers are running on different subnets, then you must specify a range of IP addresses that the client should use to connect to the primary server. For example:

...UID=user12;PWD=x92H4pY;ENG=mirrordemo;LINKS=tcpip(HOST=ip1,ip2...)...

You may also want to specify the RetryConnectionTimeout connection parameter to control how long clients keep retrying the connection attempt to the primary server. See RetryConnectionTimeout connection parameter [RetryConnTO].

If you are having trouble locating the server to which clients need to connect, try the following:

  1. Specify the host name of the computers running the primary and mirror servers. For example, if they are running on computers named MirrorServ1 and MirrorServ2, you can use LINKS=tcpip(HOST=MirrorServ1,MirrorServ2) in the client connection string.

  2. Register the servers with LDAP. See Connecting using an LDAP server.

  3. Use the SQL Anywhere Broadcast Repeater utility (dbns10) to locate the servers. This utility listens for broadcasts and responses on one subnet, and then re-broadcasts them on another subnet. See SQL Anywhere Broadcast Repeater utility (dbns10).


Specifying a preferred database server
Forcing a database server to become the primary server
Initiating failover on the primary server
Stopping a database server in a mirroring system
Recovering from primary server failure