Skip navigation links

MySQL Forums :: Replication :: Replication began to work not always, not right away


Advanced Search

Re: Replication began to work not always, not right away
Posted by: Dan Mor ()
Date: April 06, 2012 07:33PM

So I have problem again!
After 2 days of good working, replication hangs up again!
And I do not make any changes to settings last days. It corrupts by its own.

For now table ibf__uag_gvars is not updating while replicating.
(while relay logs are changing and seconds_before_master==0)

BUT..

I make UPDATE to another table
UPDATE `jedif1`.`ibf__uag_banlist` SET `member_id`='111' WHERE `id`='1';
and it UPDATES on the slave too!.

and after this query, new queries on ibf__uag_gvars start to work! O_o
(but previous changes was not taken)

how I know when this SLAVE hungs up again?.. How to prevent it?..

-----------------------------------
> EXPLAIN EXTENDED SELECT * FROM `ibf__uag_gvars` WHERE `name`='defaultShipSpeed';
> SHOW WARNINGS;

id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE ibf__uag_gvars const PRIMARY PRIMARY 66 const 1 100.00

Level Code Message
Note 1003 select 'defaultShipSpeed' AS `name`,'0.21155' AS `value`,'0' AS `private` from `jedif1`.`ibf__uag_gvars` where 1


-----------------------------------
> SHOW PROCESSLIST

Id User Host db Command Time State Info
33032 system user \N Connect 191211 Waiting for master to send event \N
33033 system user \N Connect -8 Slave has read all relay log; waiting for the slave I/O thread to update it \N
50719 root localhost:64130 jedif1 Query 0 \N SHOW PROCESSLIST
50724 root localhost:64141 \N Sleep 1048 \N



-----------------------------------
PS. here ibf__uag_banlist

CREATE TABLE `ibf__uag_banlist` (
`id` mediumint(9) NOT NULL AUTO_INCREMENT,
`ip` varchar(20) NOT NULL,
`member_id` int(11) NOT NULL DEFAULT '0',
`disturber` varchar(40) NOT NULL,
`type` int(11) NOT NULL DEFAULT '0',
`datetime` int(10) NOT NULL,
`datetime_end` int(10) NOT NULL DEFAULT '0',
`judge_id` mediumint(9) NOT NULL,
`reason` text NOT NULL,
`in_force` tinyint(1) NOT NULL,
`password` varchar(8) NOT NULL,
PRIMARY KEY (`id`),
KEY `NewIndex1` (`datetime`),
KEY `NewIndex2` (`member_id`)
) ENGINE=MyISAM AUTO_INCREMENT=38034 DEFAULT CHARSET=cp1251 CHECKSUM=1 DELAY_KEY_WRITE=1 ROW_FORMAT=DYNAMIC



Edited 1 time(s). Last edit at 04/06/2012 07:34PM by Dan Mor.

Options: ReplyQuote


Subject Views Written By Posted
Replication began to work not always, not right away 1038 Dan Mor 03/31/2012 02:47PM
Re: Replication began to work not always, not right away 516 Rick James 04/01/2012 05:37AM
Re: Replication began to work not always, not right away 609 Dan Mor 04/02/2012 12:47PM
Re: Replication began to work not always, not right away 483 Rick James 04/03/2012 08:58AM
Re: Replication began to work not always, not right away 476 Dan Mor 04/04/2012 02:26PM
Re: Replication began to work not always, not right away 461 Rick James 04/05/2012 07:36PM
Re: Replication began to work not always, not right away 543 Dan Mor 04/06/2012 07:33PM
Re: Replication began to work not always, not right away 466 Rick James 04/07/2012 03:57PM
Re: Replication began to work not always, not right away 741 Dan Mor 04/07/2012 08:08PM
Re: Replication began to work not always, not right away 468 Rick James 04/08/2012 03:41PM
Re: Replication began to work not always, not right away 541 Dan Mor 04/14/2012 11:14AM
Re: Replication began to work not always, not right away 449 Rick James 04/15/2012 11:47PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.