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

Branch merges

Propose for merging

No branches dependent on this one.

Ready for review for merging into lp:mysql-fabric

Oracle/MySQL Engineering: Pending requested 2014-05-04

Diff: 103 lines (+45/-4)

2 files modified

lib/mysql/fabric/command.py (+4/-2)
lib/mysql/fabric/services/health.py (+41/-2)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

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