Hi Jon,
The cluster has been configured correctly with this basic settings:
- Two systems (W2003) with 2 postgre 8.3 (one each), 2 HSQLDB 1.8 for
the RecoveryLogs (one each) and 2 sequoia controllers (one each)
clustering with JGroups
- Sequoia won't be loaded at boot, since as is a cluster, you don't
now why did the machine boot (failure, maintenance, ...), so it has no
sense. Is this ok?
This is correct. Some have tried to use Sequoia as a service in Windows
(see
http://fossplanet.com/db.sequoia.general/message-188232-sequoia-windows-service/)
but an automatic start is likely to fail without proper diagnostic.
I have two questions regarding the "jump" to production systems:
- For the periodic manteinance of the cluster backups, how could some
console commands (backup a backend, purge RLog1, transfer and purge
RLog2) be put in a batch job (W2003)?
You can probably use a cron replacement for Windows like
http://sourceforge.net/projects/cronw/. Otherwise the Windows Task
Scheduler should do the job (tutorial at
http://www.iopus.com/guides/winscheduler.htm).
- How could the two sequoias be monitored and health checked from the
"network"? Just checking the ports shouldn't be enough...
It depends what kind of health you want to check. You can connect with
the console and check the backends status and check that you still have
enabled backends. Another option is to execute a simple SELECT statement
and make sure that you get a result back.
Hope this helps,
Emmanuel
Jon Urionaguena escribió:
Thanx Emmanuel,
I will keep you informed.. ;-)
Emmanuel Cecchet escribió:
Hi Jon,
Then in the config, I should use a RAIDb-1 config in each
controller specifying just one backend in each (so, not doing
mirroring inside de RAIDb...)? I cannot specify the two same
backends to the two controllers, can I?
You are correct, just 1 backend in each controller. You cannot share
backends between controllers.
Keep us posted with your progress,
Emmanuel
Emmanuel Cecchet escribió:
Jon,
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?
No, SingleDB can only be used with one controller without
replication. If you need replication, you have to use RAIDb-1 with
a <Distribution> element in the virtual database configuration
file so that the controllers are synchronized. Each controller can
have a single database backend but the virtual database will have
a total of 2 replicated backends that will appear as a single
database to the client application.
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?
Yes, it is. You can look at the distributed RAIDb-1 demo that
ships with Sequoia. You can change the config to have a single
backend per controller and that should be similar to what you need
to build.
I will use another small database in each controller for the
RecoveryLog...
Thanks for your interest in Sequoia,
Emmanuel
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
--
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
--
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
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
