It's good to know. Keep up with good work, cheers!!
--
*Wagner Bianchi, MySQL Database Specialist*
Mobile: +55.31.8654.9510
E-mail: m...@wagnerbianchi.com
Twitter: @wagnerbianchijr
2014-09-06 3:01 GMT-03:00 Ajay Garg ajaygargn...@gmail.com:
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
