Thank you for your reply, from what I have read the latest version of mysql is multimaster capable and various other types of replication. I am wondering what would be more latency sensitive or even bandwidth intensive, Jboss Cache or database replication. If I am doing ticket storage at the cluster level across datacenters, then database level replication is only for persistence right ? So, by your last statement its best to span the cluster across the datacenters over TCP ?
I can imagine the replication would be a bandwidth hog, while latency might be prohibitive. The workload on the CAS ticket registry is very read/write intensive, so you're going to generate a lot of data to replicate. If you wanted to have multiple nodes in the database serve as masters where they need to receive each updates from one another, I would think the latency would significantly reduce throughput. Also, I'm not up on MySQL clustering, but the only clustering setup I'm aware of is master-slave. Is mulit-master replication even an option? I wonder if another ticket storage mechanism like memcached or JBoss Cache would be more well-suited to this case. > 2) Load balance between the data centers using technology such as Big IP's > GTM . You'd still have to devise a solution to share ticket state between nodes in a cluster that spans data centers. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user CONFIDENTIALITY: Any information contained in this e-mail (including attachments) is the property of The State of Texas and unauthorized disclosure or use is prohibited. Sending, receiving or forwarding of confidential, proprietary and privileged information is prohibited under Lamar Policy. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
