Hello Andres,
the syncman gui is not a remote control to start or stop the
synchronization processes. (Such an idea would also imply
permanent network connectivity to all participating machines,
which is in fact not necessary, and this is one of the
most important features of Synchronization Manager.)
The synchronization processes on each machine are started/stopped
using the shell commands
'syncservice start -d <database name>', resp
'syncservice stop -d <database name>'.
(refer to the documentation and the example which comes
with synchronization manager)
In that you tried to start/stop the synchronization processes
with the gui you actually enabled/disabled parts of
your synchronization scenario definitions.
If a unit is deactivated, no more data is gathered and propagated
for that unit, which is not what you want to happen when you
just want to stop the synchronization service for a database.
some months ago I wrote an analogy to clarify this misconception
(which seems to be common) for an other SyncMan user:
The message server acts as the central hub through which
the syncservice programs (one syncservice attached to each participating
database)
exchange all their information.
One could compare this with a corporate email system in a company where
the employees do a lot of travel and are equipped with laptops.
The laptops have email clients installed (e.g. outlook):
- employees <==> databases
need to exchange informations to stay in synch
- email clients on their laptops, offline, not being
connected to the corporate network (somewhere at a customer,
on an airplane, etc) <==> shadow tables in the database, in a special
schema,
transparent to the database's operation
collect and store new informations for being sent
later.
(One can write emails while sitting in the plane,
but these cannot be sent immediately, they are stored
in the 'outbox')
- the email clients being online (at the airport lounge, back in office,
etc)
<==> the attached syncservice programs, running
the collected information is transferred to the
information exchange hub, and information from others
is received from there
- the company's email server <==> the message server
receives information from the clients and dispatches
it to them, according to some set of rules.
- the data storage system of the email server (e.g. a large hard disk, a
database system)
<==> the message server database (more precisely, the 'MESSAGESERVICE'
schema)
an implementation detail of the information exchange hub.
can happen to be a database or a schema in such.
- the email server administrator <==> the syncman gui
configures the rules for dispatching information in the hub,
also configures the clients initially.
doesn't see much employment after the initial setup is done,
used occasionally when new clients must be set up or
when dispatch rules are altered.
- mailing lists, forwarding directives, filtering rules, out-of-office
settings, etc
<==> column groups, synchronization units, all the abstractions in the
syncmangui
terms of the language used to define information dispatch
rules at the hub,
and mode of the client's operation.
regards,
Markus
-----Original Message-----
From: Andres Rebolledo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 13, 2006 6:54 PM
To: [email protected]
Subject: Synchronization Questions
Hello all,
I have a few questions regarding MaxDB replication:
1) I am currently testing a simple MaxDB replication scenario. We have
one Master unit and two clients units, all of which are in/out units.
Synchronization works fine when empty client tables are populated with
content from the master. However if a client goes down, I am having
trouble getting the client to re-sync properly without clearing the
database first. If any updates to existing records take place while the
client is down, these changes are not propagated to the client. And any
future tables to the table are not propagated. I have read in a MaxDB
user report that MaxDB has problem when you try to synchronize a client
table with data already exisiting in it. Must the client records be
deleted in order to properly resynchronize or is there any way to
resynchronize without clearing the database?
2) Is it possible to automate the startup procedure replication rather
than use the SyncManGUI? I read on #maxdb IRC that I would have to
write some Java code which calls the synchronization functions used by
SyncManGUI. However there is no documentation of the Java
synchronization classes and the source files are not included in the JAR
files. Has there been any work done on automatically starting Master
and Client replication units? Is there any documentation available that
may assist in creating an automated startup procedure?
Thanks,
Andres Rebolledo
www.zebraprojects.com
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
