0

There are n clients, the main concern is that is most of them is online (the more the better) as much time. There is only one server, for reasons of budget and power consumption. I have seen this problem from many angles, most exposed in this discussion Strategies for Java ORM with Unreliable Network and Low Bandwidth then summarized my options.

  1. Clustering. Using terracotta and using a second server (passive) installed on a node.
  2. Replication / Synchronization. My original idea: Allow nodes to be offline during network failures and then restart operations.

What do you recommend?

PS if there is something wrong in my reasoning please tell me

Community
  • 1
  • 1
ZooMMX
  • 838
  • 9
  • 14
  • 1
    No this is not easy. Are you talking about clustering/replicating the server where hibernate is running or clustering/replicating the database itself? The article you refer to seems to be about dealing with unreliable connectivity to the database and unreliability of the database. You only have one server you say, so where are you replicating? – djna Jul 11 '11 at 17:21
  • You say "clients" -- clients of what? If they are clients to your *one* server and it goes down, they will ALL experience the downtime (and all the clustering / replication in the world won't help). If in fact they're configured as a cluster or something, please don't call them "clients" -- they're servers too. – Chris Eberle Jul 11 '11 at 17:23
  • Sorry if I was unclear. That's the current configuration I want make some changes. In fact today if the only server goes down, all system goes down, that's the problem. So I'm thinking that I can implement a cluster solution or a replication solution with a local database in every node. Thanks for your interes djna and Chris! – ZooMMX Jul 11 '11 at 17:49
  • Also the system has low workload, the full uncompressed mysql database is only 1.5 gb with 18 months data. – ZooMMX Jul 11 '11 at 17:56
  • It is incredibly unclear what the actual question here is. Is it just "what do you recommend for clustering/replication/failover options?" – matt b Jul 11 '11 at 18:45

2 Answers2

1

Thanks for those thoughts. The application is a simple point of sale. After thinking and analyzing your answer I will try to store users, products and sales in DSO's (using some boxes as servers and nodes at the same time). At one time the server with the database is available pour the sales according to the producer-consumer pattern.

And an apology for my short communication skills, I'm still learning English!.

ZooMMX
  • 838
  • 9
  • 14
0

I think you are saying that you have a single machine, on it you have both an application using Hibernate and a MySql database. If you lose that machine your users cannot work. You are asking whether some additional resilience is possible and believe that you have identified two solutions.

You don't give much detail about either solution, so I'm not going to try to second guess what you have in mind.

You also don't say much about about the nature of the application. If (for example) it was entirely read-only, no database updates then replication is comparatively easy. If all writes are additive and cannot conflict (for example some kind of opinion poll, vote yes/no) then again replication with perhaps a bit of queueing is comparatively easy.

However a traditional application with users updating shared data, where a consistent view is important (for example we don't want to sell the last available hotel room twice) then replicating gets tricky.

One approach is to separate the database to a highly resilient tier, products such as Oracle RAC have very clever resilient characteristics, and I guess you pay for cleverness. Once you have a resilient database then clustering your application becomes much easier. I often see lots of cheap boxes running the app in parallel because the definitive "truth" is managed by the DB.

However, even this is tricky unless the app was designed up-front for replication. You find all manner of subtle assumptions are made on the basis of the App is some sense being able to rely on it's previous view of truth. Products like Terracotta may well (I've never tried, so I don't know) help to implement a resilient design but unless the design is well thought through it may have business flaws.

I interpret your idea as being to run multiple parallel copies of the app and db and the deal with synchronisation issues. Only you know whether this makes sense for your business requirements. You would be opening up the possibility of inconsistency, especially in the times when failures have occurred and resynchronisation has not completed.

djna
  • 54,992
  • 14
  • 74
  • 117