On Tue, Apr 26, 2011 at 3:53 AM, Steve Singer <ssinger at ca.afilias.info> wrote:
> On 11-04-22 06:25 AM, Stuart Bishop wrote:
>>
>> On Sat, Apr 16, 2011 at 2:41 AM, Christopher Browne
>> <cbbrowne at afilias.info>  wrote:
>>>
>>> On Fri, Apr 15, 2011 at 2:16 PM, Steve Singer<ssinger at ca.afilias.info>
>>>  wrote:
>>>>
>>>> C)  We could get rid of try blocks.  Some people have commented that
>>>> they don't behave as expected anyway and with the additional
>>>> restrictions of changes 1) and 2) they are even less useful.
>>>
>>> I'd point not only to "less useful," but also to "less able to be
>>> reasoned about" as an issue.
>>>
>>> The "intuitive" position is that TRY blocks are supposed to look like
>>> something quasi-transactional; if there's a failure, "everything
>>> should be rolled back."  That's certainly a cool idea to consider.
>>>
>>> Unfortunately, that's not remotely near to being how things are.  If
>>> there are activities inside a TRY block that cross multiple nodes,
>>> it's not reasonable to expect that all to roll back.  (We're not using
>>> 2PC!)
>>
>> But it does seem to work well enough...
>>
>> eg. execute a number of SQL scripts in a try block. If one of them
>> fails when applying to the master, it all rolls back. If they all
>> work, the events get propagated and they are applied on the slaves and
>> if this fails you have other problems. It might not be perfect, but it
>> is better than a kick in the teeth and I would like to keep it.
>
> So how do you feel about slonik obtaining the sl_event_lock on all nodes
> while it performs the execute script.   The concequence of this is that no
> new SYNC events will be generated on any node until ALL of your execute
> scripts (in that try block) commit.
>
> This would mean that if you have nodes  1 hosting set 1, and node 2 hosting
> set 2 an EXECUTE SCRIPT (or anything else) in a try block on node 1 would
> pause replication from node 2 (even between nodes 2 and 3).  Of course if
> you don't use a try block then sync event generation on node 2 won't be
> paused.

Me? I have no problem with that. My applications already have to cope
with lag because I'm using asynchronous replication, so I'm not
particularly fussed if replication on the cluster stops completely
while I'm twiddling stuff with slonik.

My goal would be to minimize locks on table, increasing my chances of
any particular change being able to run on the live system. I think
this is already the case in 2.0.


-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/