You can try these steps: 1-) Stop slave and write down the replication coordinates getting that in MySQL's error log (*very important step*); 2-) Issue the `reset slave` command on MySQL Slave; 3-) Issue the CHANGE MASTER TO considering the replication coordinates you've just written down on step 1; 4-) Give replication a start; 5-) Check if the issue has gone away.
If you're not comfortable to do that, just share the SHOW SLAVE STATUS output with us. Let us know how's it going, cheers!! -- *Wagner Bianchi, MySQL Database Specialist* Mobile: +55.31.8654.9510 E-mail: m...@wagnerbianchi.com Twitter: @wagnerbianchijr 2014-09-04 7:24 GMT-03:00 Ajay Garg <ajaygargn...@gmail.com>: > Hi all. > > Unfortunately, I have run into the logs, as described at > http://bugs.mysql.com/bug.php?id=71495 > > Unfortunately, the issue does not go away, even after reverting back > to "slave-parallel-workers=0" in "my.cnf", and restarting the mysql > instance. > > > Any quick idea, as to how we may get the mysql+replication up and > running (even with the plain old non-multi-threaded mode)? > > > > > On Tue, Sep 2, 2014 at 12:57 PM, Ajay Garg <ajaygargn...@gmail.com> wrote: > > Thanks Akshay for the reply. > > > > On Tue, Sep 2, 2014 at 12:25 PM, Akshay Suryavanshi > > <akshay.suryavansh...@gmail.com> wrote: > >> Hello Ajay, > >> > >> I tried testing the slave-parallel-workers few months ago, what I can > surely > >> tell you its still under development, and at that time needed some > critical > >> bug fixing. > >> > >> It is helpful in situations where each schema has even workload. The > case > >> you mentioned above doesnt have so. DB2 is getting different type of > load > >> than the others, in that case the other slave workers should be able to > >> proceed with their workload as opposed to db2 which is still executing > the > >> long running statement. Now just imagine what happens if we try to take > a > >> backup, what binlog position should be captured ? the show slave status > will > >> print what ? this is where it needs development, I tried testing > backups on > >> it, but there is no concrete documentation on what position it would > fetch. > >> > >> db2-statement-1 (very, very long-running) > >> db2-statement-2 (short-running) > >> > >> about the above scenario, the next db2-statement-2 it will wait for the > long > >> running statement-1 to complete. > > > > Surely.. !! :) > > > > > > However, my concern is how this "tracking" is done. > > That is, how is the db-wise segregation of statements done (from a > > single-binlog-file originally coming onto the slave) ? > > > > If this segregation is not done, then I cannot think of a way on how > > things would scale up, like for example, when the slave-relay-log-file > > contains a random mix of statements from tens of different databases. > > > > > > > > Any pointers on the "actual current" implementation of this db-wise > > statements-segregation will be a great confidence-booster !! :) > > > > > > > > Thanks and Regards, > > Ajay > > > > > > However db2-statement-2 can be picked up by > >> any other sql worker thread. > >> > >> This is a good feature added in mysql, however still needs to go > through lot > >> of testing. Please share your observation and findings in case it > differs > >> from the above. > >> > >> Cheers!!! > >> Akshay > >> > >> > >> On Mon, Sep 1, 2014 at 8:27 AM, Ajay Garg <ajaygargn...@gmail.com> > wrote: > >>> > >>> Hi all. > >>> > >>> > >>> We have replication set-up, where we cater to HUUGEE amounts of data. > >>> Since quite some time, we have been facing issues wherein the slave > >>> lags behind master quite a lot. > >>> > >>> > >>> So, yesterday we were able to setup parallel replication, by > >>> incorporating the following changes :: > >>> > >>> a) > >>> To begin with, partitioned some tables into dedicated databases. > >>> > >>> b) > >>> Set up the "slave-parallel-workers" parameter. > >>> > >>> > >>> The above seems to work functionally fine, but we have one doubt/query > >>> about the scalability of this solution. > >>> > >>> > >>> > >>> > >>> First, I will jot down the flow as far as I understand (please correct > >>> if wrong) :: > >>> > >>> """ > >>> Even in parallel-replication scenario, the master writes all the > >>> binlog (combined for all databases) in just one file, which then gets > >>> passed onto the slave as single-file itself. Thereafter, all the > >>> replication commands (combined for all databases) are written > >>> sequentially onto one slave-relay file. > >>> > >>> Thereafter, as per the documentation, the slave-SQL-Thread acts as the > >>> manager, handing over commands to worker-threads depending upon the > >>> databases on which the commands run. > >>> """ > >>> > >>> > >>> > >>> So far, so good. > >>> However, what would happen if the slave-relay file contains the > following > >>> :: > >>> > >>> > >>> db1-statement-1 (short-running) > >>> db2-statement-1 (very, very long-running) > >>> db2-statement-2 (short-running) > >>> db1-statement-2 (short-running) > >>> db1-statement-3 (short-running) > >>> > >>> > >>> We will be grateful if someone could please clarifiy, as to how the > >>> above statements will be managed amongst the Manager and the > >>> Worker-Threads (let's say there is just one worker-thread-per-db) ? > >>> > >>> In particular, does the Manager thread creates internal > >>> slave-relay-log-files, one for per database-statements? > >>> > >>> > >>> > >>> Thanks and Regards, > >>> Ajay > >>> > >>> -- > >>> MySQL General Mailing List > >>> For list archives: http://lists.mysql.com/mysql > >>> To unsubscribe: http://lists.mysql.com/mysql > >>> > >> > > > > > > > > -- > > Regards, > > Ajay > > > > -- > Regards, > Ajay > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql > >
