Thanx Emmanuel,
I maybe didn't explain correctly my problematic issues... What we need
is the simplest arch to hold a database system with no single point of
failure, but this database (composed by two backends in the simplest
form) should look as only one to our apps. So what I think is that we
MUST use two controllers, and I was looking for the correct
implementation. As I see, two controllers could use a singleDB each (I
could not start this config... I will review this case if it's the
correct for us...). Is that ok?
Then the question should be, if these two database backends, each
controlled by a different controller, are indeed replicated (we can
recover one from the other in case of failure), the database system is
fault tolerant with no single point of failure, and functionally perfom
as a single database to the application... Is this Ok?
I will use another small database in each controller for the
RecoveryLog... Thanx a lot
Best Regards,
Jon
Emmanuel Cecchet escribió:
Hi
Jon,
I'm new to the list and to sequoia, and so
I'm trying to understand and realize the capabilities of this product.
Welcome and thanks for your interest.
We are trying to find a database architecture
as the backend for our Java apps, with the only requisite of four nine
availability (99,99). The load will always be low. My view is from the
infrastructure point (I know that I should pass this problem to our dev
part, I've done it indeed...), and that's why I want to build a base
platform for deploying different client solutions in our virtualized
datacenter: My needs should be just two backend databases ("mirrored"
ideally) controlled by two controllers replicating everything.
If you need only 2 database backends, they can also be under the same
controller. The controller becomes a single point of failure but this
can be fine if it is co-located with the application and the
application is not clustered. Now if your application is also
replicated, you can have 2 controllers with 1 db each.
I was looking at Sequoia+Postgre as the
platform, and have been reading all the documentation it seems to fit
well. I have some doubts:
1) Which should be my simplest configuration? RADIb-1 in each
controller would give me 4 backends... That is supposing that two
controllers cannot control the same two backends, is that allright?
RAIDb-1 is for mirroring so you are on the right path. You are right
that backends cannot be shared between controllers. But one controller
can have multiple backends. So I am not sure if you just need to
replicate 2 databases on different machines which will lead to 4
backends (2 for each controller as you mentioned) or just 1 database in
which case 1 backend per controller is enough.
2) I tried using simpleDB in each controller,
but I got errors saying that no distribution can be done with
simpleDB... Is that allright?
SimpleDB is only meant for 1 database backend only (cluster-wide). If
you replicate a database, you have 2 backends in the cluster and you
need RAIDb-1.
3) In the configs I'm proposing, where should
the RecoveryLogs be stored? In the same backends (maybe only in one of
the two?) that compose the DBclusters?
I usually recommend to have the recovery log local to each controller.
Given the small workload that you will have, a Java database like Derby
or Hsqldb can do it on the controller.
Hosting the recovery log on a database backend is error prone for
administration and when you need to service the database node you will
have to stop your controller that will not be able to work without its
recovery log.
I hope this helps,
Emmanuel
--
Jon Urionaguena Mendizabal <[EMAIL PROTECTED]>
Director de Proyectos www.nesys-st.com
Tfno: 94 406 0546 Móvil: 675 610 399
GPG: 01D3 27A9 A663 C89E 3F72 2C5B 4913 E546 C4AA 2A97
|
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
