Thanx Emmanuel!!
I'll try that,
Jon
Emmanuel Cecchet escribió:
Hi
Jon,
The console can take the commands from a script file. Look at the demo
files and how they script the console.
The command looks like: console.bat -p 1090 -f
..\demo\init_derby_raidb1.script
Hope this helps,
Emmanuel
Just one point about the console commands in batch mode... How can they
be issued? Is there anything documented in the manuals? I couldn't see
how to make a windows batch file to execute a backup (for example...).
Is there any console command to be launched scheduled and admiting
parameters?
Best regards,
Jon
Emmanuel Cecchet escribió:
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
|
