Comment 2 for bug 1161432

Hello again!

It seems I have figured out what the problem is. mysql_tzinfo_to_sql produces an SQL script like the following:

TRUNCATE TABLE time_zone;
TRUNCATE TABLE time_zone_name;
TRUNCATE TABLE time_zone_transition;
TRUNCATE TABLE time_zone_transition_type;
INSERT INTO time_zone (Use_leap_seconds) VALUES ('N');
SET @time_zone_id= LAST_INSERT_ID();
INSERT INTO time_zone_name (Name, Time_zone_id) VALUES ('Africa/Abidjan', @time_zone_id);
INSERT INTO time_zone_transition (Time_zone_id, Transition_time, Transition_type_id) VALUES
 (@time_zone_id, -1830383032, 1)
;
INSERT INTO time_zone_transition_type (Time_zone_id, Transition_type_id, Offset, Is_DST, Abbreviation) VALUES
 (@time_zone_id, 0, -968, 0, 'LMT')
,(@time_zone_id, 1, 0, 0, 'GMT')
;
[.... LOTS of INSERT statements .....]

It appears that INSERT statements are not replicated to other nodes, because they belong to MyISAM tables, and the cluster's default configuration does not replicate MyISAM table rows. Apparently, though, TRUNCATE TABLE statements ARE written to the binary log, because they are considered DDL statements. The result is that if you execute the above script on the master, the tables are truncated and populated with data. On other nodes, the tables are truncated and left empty.

The obvious solution that I used to solve the problem, was to comment out the TRUNCATE statements and run them manually once on a node. This empties the timezone tables on all nodes of the cluster. After that, I ran the script full of inserts on each and every node individually. Now, all nodes have timezone information.

I suppose the mysql_tzinfo_to_sql script provided with the percona server could be changed to use DELETE statements instead of TRUNCATE ones to overcome this problem.

Hope that helps.