> I am trying to integrate an Enterprise level application to PostgreSQL.
> I need answers to some questions:
>
> This is what we are planning:
>
>
> +---------------+
> + Storage +
> + Area +
> + Network +
> +---------------+
> +
> +
> -----------------
> | |
> Master Server 2nd Master
> with eRServer Server
> for load balancing
> with eRServer
>
>
> PostgreSQL can run only one server, right?
Right.
> The PostgreSQL servers use SAN for storing data.
>
> So let's say we want to do some operation on the database, located at SAN.
> When the 1st server wants to update a row, it will lock it. What happens
> when the second server wants to access the same row? Does 1st server
> "broadcast" that it has locked the row?
>
> Or... does MVCC have something with this?
>
> How do we balance the load? Does eRServer do it; or should we use another
> thing?
>
> Maybe I need some documentation about these...
The approach we take is that all of the transactional activity takes
place on the "master" system, that being any activity that either
performs updates, or which requires authoritative information.
Things that are more oriented towards "reporting" take place on the
duplicate server. Some observations about this:
-> It takes load off the main server;
-> Reports commonly don't have to be "up-to-the-instant accurate."
The question of where processing should take place may be assessed by
asking two questions:
-> Does the query update information? If so, it needs to hit the master.
-> Does a query forcibly require the data to be _absolutely_ up to date? If it's good enough to be "within the
nearestfive minutes," then it's acceptable to hit a secondary server, but if not, it has to hit the master.
The vital point here is that it's a one-way data flow from the master to
slave servers. Data never flows in the other direction.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/rdbms.html
"You think you know when you can learn, are more sure when you can
write, even more when you can teach, but certain when you can
program." -- Alan Perlis
