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
