lp:~martinarrieta/mysql-fabric/BUG-71445

Created by Martin Arrieta on 2014-05-03 and last modified on 2014-05-13

BUG#71445 and BUG#72511

This branch add support to Json in the return field in order to be able to use it to display the result with a better format.

I also added:

1- The address field in the group health command
2- command_status method on /lib/mysql/fabric/services/health.py in order to make an example about how we can display the output.

Regards,

Martin.

Get this branch:
bzr branch lp:~martinarrieta/mysql-fabric/BUG-71445
Only Martin Arrieta can upload to this branch. If you are Martin Arrieta please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Martin Arrieta
Project:
MySQL Fabric
Status:
Development

Recent revisions

228. By Martin Arrieta on 2014-05-04

Fixed error with groups that does not exist

227. By Martin Arrieta on 2014-05-04

Changed the method from dispatcher to command_status

226. By Martin Arrieta on 2014-05-04

fixex the group health command

225. By Martin Arrieta on 2014-05-03

Adding Json support for the result

224. By Martin Arrieta on 2014-05-02

added the address of the servers to the group health command

223. By Alfranio Correia <email address hidden> on 2014-03-25

BUG#72117: BUG#18454582: SCHEDULER DOES NOT NOTIFY ALL PROCEDURES THAT ARE FREE TO GO AFTER A RELEASE

The scheduler is not notifying all procedures that were blocked by a procedure
that has had its locks released. The current algorithm checks all the queues
for the objects locked by the procedure which has finished but does not check
that some procedures are at head of the queue already for other objects.

For example,

   ['object_1'] = [procedure_1, procedure_2]
   ['object_2'] = [procedure_2]

If "procedure_1" finishes the execution, the scheduler does notify that
"procedure_2" can continue its execution because only the queue for
"object_1" has changed after releasing the locks for "procedure_1".

222. By Alfranio Correia <email address hidden> on 2014-03-18

BUG#72016 BUG#18403885 AUTOMATIC FAILOVER IS NOT HAPPENING WHEN GLOBAL GROUP MASTER IS FAILED

The shard sub-system creates a replication channel between a global group and
a shard group. Specifically, the master in the global group replicates its
changes to the master in the shard group.

Although there is this relationship, the high availability routines should
work independently in the sense that any high availability operation in the
groups should work regardless the existence of a valid master or not in the
related group(s). This was not happening though and an exception was raised
thus aborting the high availability operation(s).

We have fixed this behavior in the context of this patch. Now if there is
no valid master in a related group, an error message is printed out and
the operation continues.

221. By Johannes Schl├╝ter on 2014-03-10

Merge 1.4

220. By Mats Kindahl on 2014-03-07

Merging with trunk

219. By Mats Kindahl on 2014-03-07

Releasing version 1.4.2

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:mysql-fabric
This branch contains Public information 
Everyone can see this information.

Subscribers