03.01.2012 19:44, Ann Harrison wrote: > I'm not sure that either replication or the > mechanism Sean is proposing (similar to either the start of a shadow > database or nbackup) can solve the overflowing transaction id problem.
Simply: let's say we have two synchronous database. One is primary and the second is... well... secondary. When transaction count reach, say, 1000000000 transaction, we shut down replication and perform backup-restore of the secondary database. Then we continue replication and after some time we again have two synchronous databases. In primary database transaction counter is big, in secondary - low. Now we switch the roles. Primary database become a secondary and vice versa. After then we can repeat previous step to reset transaction counter in ex-primary database without stopping whole system. Voila. -- SY, SD. ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
