Hmm, how about this?
DB2 Multisystem overview
DB2® Multisystem is a parallel processing technique that provides greater scalability for databases.
Using DB2 Multisystem, you have the capability to attach multiple System iT models (up to 32 systems) together in a shared-nothing cluster. (Shared-nothing means that each system in the coupled network owns and manages its own main memory and disk storage.) As soon as the systems are connected, database files can be spread across the storage units on each connected system. The database files can have data partitioned (distributed) across a set of systems, and each system has access to all of the data in the file. Yet to users, the file behaves like a local file on their system. From the user's perspective, the database appears as a single database: the user can run queries in parallel across all the systems in the network and have realtime access to the data in the files.
Check the Information Center for more details...
-Eric DeLong
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Matt Olson
Sent: Monday, March 11, 2013 3:51 PM
To: Midrange Systems Technical Discussion
Subject: RE: Bi-directional transactional replication on IBM i
Not sure how you would mirror disks located in two separate datacenters :-)
We need a share nothing type of solution like what is shown in those diagrams I showed in the MS SQL examples.
Here is the previous post on what I'm looking for (I posted it under the wrong subject, doh!):
If either one of the systems go down, they both go down. I'm not looking for a high availability solution. I'm looking for:
1. User issues INSERT statement on SERVER A, it gets replicated to SERVER B.
2. If user issues INSERT on SERVER B, it gets replicated to SERVER A.
Rules:
1. An INSERT is not committed to either system until it has replicated to the remote system.
I'd also settle for a topology where if rule #1 can't be obtained out of the box then whichever system was the first one to INSERT wins, and the last one to UPDATE wins.
As I understanding it journaling does most of this, but I have found no documentation that states how to do bi-directional and also shows you the topology diagrams along with the control panels/GUI tools that aide in conflict resolution, as well as how to define conflict resolution rules within IBM i DB2.
Again, documentation seems scarce on this subject. Very plentiful in LUW and other DB platforms. Just point me to the redbook please :-)
-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Monday, March 11, 2013 3:46 PM
To: Midrange Systems Technical Discussion
Subject: Re: Bi-directional transactional replication on IBM i
I'm looking for something akin to this type of replication in SQL 2012
The web page you referenced sites a couple use cases:
1. Improved read performance, because reads are spread out over two servers.
2. Higher availability if maintenance is required or in case of failure at one node.
For improved read performance we chose to go with mirrored disks under IBM i. Since the files exist on 2 disks - more jobs, processors, etc. have simultaneous access. Wouldn't mirrored disk be easier to manage than mirrored DB servers?
Mirrored disks also support higher availability. If one disk fails, the other picks up the load.
-Nathan.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
