Hi Wagner. That is what I did as the last resort, and that is "only" what solved the issue.
Thanks. On Fri, Sep 5, 2014 at 1:52 AM, wagnerbianchi.com <m...@wagnerbianchi.com> wrote: > 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 >> > -- Regards, Ajay -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
