Hello Andy,
> -----Original Message-----
> From: Andy Chan [mailto:[EMAIL PROTECTED]
> Sent: Montag, 16. Februar 2004 09:32
> To: Montag, Marina
> Subject: RE: dbmcli: hss_ commands
>
> > Hi Marina,
>
Marina asked me to do her the favour to answer your questions. I hope to clarify some
things with a little introduction of HSS first...
What is HSS?
An abbreviation for Hot Standby Storage. It is a special HA Enhancement of our
database... HSS uses shared LOG-Volumes for (read+write access) Master and (read-only
access) Standbys and individual (read+write) data volumes, which are copied once for
each Standby. The data volume content is completely copied during 'hss_addstandby'
command!
Before the copy action, the master writes a savepoint that allows the standby to
'continously recover' until he is informed to 'takeover' or until stopped.
A HSS solution normally needs two other important components: A cluster software (i.e.
HACMP) and a SAN that supports FastCopy (explained below).
The 'copy action' is needed during setup of Standby only, but nevertheless should be
supported by the storage system for large data volumes. The data volume copy is not a
mirror, but independent (read+write!) after the copy is done.
After the copy action is initialized and allows write access to the Standbys data
volumes, the master sends 'SYNCHRONIZE' packets to keep the standby informed about the
latest LOG-volume activitiy. If the Standby machine is fast enough, it is only a few
(or even none) transactions behind the master. This makes it a Hot Standby. Since
failure of a master allows to switch (takeover) almost at once by the hot standby
instance.
Usable storage system current is IBM ESS (even PPRC line connections are supported),
EMC Symmetrix SYMAPI was the original target, but is currently not really supported
(If you like, do a port to another storage system look into
'sys/src/SAPDB/RunTime/HotStandbyStorage/RTEHSS_ApiCopy.c' for a good starting point).
Usefull SANs allow to connect several maschines to the same 'volumes'. The storage
systems should support a 'FastCopy'. That normally establishes a copy background job
inside the storage system, which even while copying allows writes on the Masters and
Standby data volumes! Such 'subsequent' writes are not mirrored to either copy target
(On SYMAPI you would 'establish a mirror and split the mirror afterwards. A splitted
mirror is exactly what you need! Maybe you google a bit for it..). Without such a
FastCopy feature the time of the initial copy depends on the I/O speed (which is even
worse if you have to copy via network...). If handled inside the storage system, the
time needed for the volume copy is reduced to the time needed to copy the 'superblock'
of the volumes. And if all data volumes are managed inside the storage system, no data
transfer via network connection is needed for the whole transfer!
Our tests using 'libhsscopy' which is a test scenario support library. 'libhsscopy'
can live without a expensive storage system, but uses a simple 'remote copy' loop. It
is not thought to be used in a productive scenario therefore.
On UNIX it also expects some preparation... It needs symbolic links
<indepData>/config/HSS_MACHINE_DATABASE/VolumeName
for each data volume on each machine. These CANNOT be established automatically, since
'<indepData>/config' is not shared between the hosts!
What we do is we put the data volumes in a directory and export it from each machine.
The symbolic links point into the mount point...
The same with the LOG-volumes which explains why i cannot recommend for a productiv
scenario. Even if you would establish a 'synchronized mirror' for the LOG-volume to
prevent a single point of failure, the page information would have to be tramitted
through your network...
On Windows it automatically creates network shares named '\\MACHINE\HSS_DATABASE' on
each hot standby host, which makes it necessary to install the 'database service'
under a user account. The default system account would not be able to use shares on
another machine. But since only a 'well known' share is needed, there is no further
administration needed. A big disadvantage of a Windows solution, is the missing
cluster file system for windows. Therefore the LOG-Volumes can be shared currently
only by using a network share.
> Just see whether you can take me a step further. I read the
> German doc, but can only guess 5% :P
>
> Will the hss commands actually create a physical copy in the standby-node?
The command hss_addstandby will actually create a physical copy of the data volumes
using the DLL configured via parameter 'HS_STORAGE_DLL'. Such a DLL must be provided
by your 'storage system' vendor. The default DLL 'libhsscopy' is just a test vehicle...
It does an actually 'remote copy' of all data volumes (see above). All HSS components
(Master + Standbys) share the LOG volume and use IDENTICAL parameter files.
>
> When there is a "log switch", will it propagate & be applied
> on standby DB automatically?
>
The 'Standbys' are automatically informed about commited transactions by 'SYNCHRONIZE'
calls, that transfer only the 'last written logical LOG-VOLUME position' and return
the 'last needed logical LOG-VOLUME position'. The LOG-Volumes are recycled, but the
Master takes care of Standbys need to
recover from LOG. Again no network traffic by copying log volume content.
>
> What I actually want to build is a equivalent of Oracle's
> "recover database until cancel" (standby DB concept), am I
> looking into the right thing?
>
You are on the right path. The Orcale concepts uses 'log file shipment'. The HSS
concept uses shared LOG-Volumes (either directly shared or PPRC synchronous copies for
separated data centers).
With a shared LOG-Volume you do not have to transfer LOG backups. To share a volume
you either need a cluster file system or raw devices (NFS is ok for testing, but leads
to another single point of failure...). For performance reason, you need the
LOG-Volumes to be accessible by all HSS-Hosts in parallel! But only Master will
write...
------------------------
Here is a short text, i got from the developer who programmed the 'high level' HSS
commands
hss_addstandby
Adds a standby to the hot standby solution.
- Writes the standby to the paramfile
- Executes a db_create on the new standby node
- Copies the paramfile to the new standby node
- Informs the master (if running) about the new standby
- Add node to all param files
Needs
- nodename
- (optional) delaytime (default 0)
- operating system user for nodename
- (optional) Installationpath (default first matching Installation - same Build)
hss_removestandby
Removes the standby
- drops the database
- Inform master
- Delete node from all param files
db_standby
Activates mode standby for a standby node. This may be a very long operation.
- restart standby
- if this fails init standby and restart standby again
----------------------
What is not explained here, is that for a 'automatic takeover' you also need cluster
software that is aware of the special status of Master and Standby instances...
> -----Original Message-----
> From: Montag, Marina [mailto:[EMAIL PROTECTED]
> Sent: 2004?2?13? 19:13
> To: '[EMAIL PROTECTED]'
> Cc: Andy Chan
> Subject: RE: dbmcli: hss_ commands
>
>
> Hallo Andy,
> The description of how to use the hss_commands in DBMCLI 7.5
> will be published with the documentation update on about
> March 20. It has just entered the translation process.
> Therefore, there is no English version available yet and I
> can offer you only a German version of an abstract on MaxDB
> Hot Standby Systems :-(
> Hope you will take comfort in this meanwhile....
> Best regards
> Marina
>
> -----Original Message-----
> From: Andy Chan [mailto:[EMAIL PROTECTED]
> Sent: Freitag, 13. Februar 2004 11:54
> To: MaxDB digest (E-mail)
> Subject: dbmcli: hss_ commands
>
>
> Hi all,
>
> Does anyone know where I can find some documentation/hint to
> use the hss_ commands in MaxDB 7.5 dbmcli interface?
>
> I've searched through the standard documentation, but can't
> anything related.
>
> Since I install the db on Linux, I don't have the easy
> Windows interface to build a hot standby. I need to go by
> typing commands...
>
> Thanks helping in advance.
>
> Cheers,
> Andy
>
>
Hope this helps a bit.
CU
jrg
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
