cferry at whenu.com
Fri Mar 5 12:42:31 EST 2004
I stopped the replication and argus caught the stop.
Whenever we've run into a transactional error replication stops and
following the above test should yield a failed test.
Is there something I'm missing?
Does replication not stop on certain transactional errors??
On Fri, 2004-03-05 at 12:07, Jeremy Kister wrote:
> On Thu Mar 4 15:48:32 EST 2004, Christopher Ferry wrote:
> > I've been using the following check successfully:
> > sql: SHOW SLAVE STATUS
> > expect: Yes
> I dont know how much testing you've done with this config, but your
> implementation will yeild false positives (ie argus will say all is ok when
> all is not ok)
> If the socket between the master and slave is ok, but there is a sql
> transactional error, your test will pass.
> Possibilities are:
> Yes Yes
> Yes No
> No No
> at the very minimum you should be using "expect: Yes Yes" (for the socket +
> SQL), but there is a question of that breaking too, as the sql server does
> not always return the same amount of rows while executing 'show slave
> status'; I dont know how different amount of rows would effect the
> positioning of each value, if at all.
> An evil co-worker could also easily foil the method, as he could start
> replicating (or ignoring) a database named "Yes" (or "Yes Yes") --
> admittedly unlikely. You'd also have to ensure neither your master nor
> slave have 'Yes' in the hostname nor username -- again, unlikely.
> Jeremy Kister
> Arguslist at tcp4me.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.tcp4me.com/pipermail/arguslist/attachments/20040305/eca9b768/attachment.bin
More information about the Arguslist