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

SAP Sybase SQL Anywhere 16.0 » SQL Anywhere Server - Database Administration » High availability and read-only scale-out systems » Database mirroring » Application development considerations with database mirroring


Requirements and restrictions for database mirroring systems

There are no special hardware or software requirements for database mirroring, and the database servers can be running in separate geographical locations. Database servers that are participating in a database mirroring system can run both mirrored and non-mirrored databases. As well, the arbiter server can be the arbiter for multiple database mirroring systems.

The following requirements and restrictions apply when using database mirroring:

  • Network database server required   Because mirroring involves network communication between the database servers, you must use the network database server (dbsrv16); the personal database server cannot be used.

    All database servers in a database mirroring system must use the same minor release; however, they can run different Support Packages.

  • TCP/IP required   Only TCP/IP connections are permitted between mirroring servers.

  • Transaction log restrictions   You cannot truncate the transaction log on the primary when you are using database mirroring because the truncation can result in lost transactions. You can rename the transaction log as often as necessary. For information about using an event to manage transaction logs in a mirroring system, see Transaction log file management in a database mirroring system.

  • Web servers   If you are using SQL Anywhere as a web server and in a mirroring system, it is not possible to specify a URL for a web request in a way that guarantees that the request is directed to the current primary server. If one of the server computers is named in the URL and that server is down, the request times out.

  • Regular back ups are still required   Database mirroring is not a replacement for a backup and recovery plan. Implement a backup and recovery strategy for your database. See Backups in a database mirroring system and Backup and data recovery.

  • DDL restrictions   Minimize the number of DDL statements executed on the primary database while an object could be in use on a copy node or the mirror server. Dropping or altering a system object may cause user connections to the mirror or copy nodes to be dropped if those connections are using the object that was dropped or altered.

  • Failover and scheduled events   If your database has scheduled events and failover occurs, the failover must complete before the events start; otherwise, the events are not executed until their next scheduled time. If the mirror server is changing to the primary server role but has not completed the transition, the scheduled event is not executed; it is executed at the next scheduled time. When an event is running and the primary server loses its connections to the mirror and arbiter servers, the event connection and all other connections are dropped. If an event is scheduled to run after the mirror assumes the primary server role, the event runs on the new primary server.

 See also