hugowan / maatkit

Automatically exported from code.google.com/p/maatkit
0 stars 0 forks source link

mk-table-sync --synctomaster port problem #110

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,
I´m trying to use mk-table-sync to sync a master-master replication, but I
think it isn´t working because lack of a port argument.

My master-master is using an ssh tunnel with remote port forwarding. This
means that the master in both servers are 127.0.0.1 on port 3307. 

I´m using this command :
mk-table-sync --test --synctomaster
h=localhost,D=intranet2,t=intra,p=blabla,u=webrefri_atlier

and the error it´s trowing is "The slave is connected to 3307 but the
master's port is 3306 at /usr/bin/mk-table-sync line 4126."

I´m I doing something wrong or is this a bug ?

Thanks

Can 

Original issue reported on code.google.com by tang...@gmail.com on 24 Oct 2008 at 2:32

GoogleCodeExporter commented 9 years ago
Forgot to mention but I did try the command with the port in the end 

mk-table-sync --test --synctomaster
h=localhost,D=intranet2,t=intra,p=blabla,u=webrefri_atlier,P=3307

But the error is the same

Original comment by tang...@gmail.com on 24 Oct 2008 at 2:37

GoogleCodeExporter commented 9 years ago

Original comment by dan...@percona.com on 12 Dec 2008 at 5:03

GoogleCodeExporter commented 9 years ago
I have a setup with ssh tunnels as well and I get the same error when trying to 
sync
a slave with it's master.
I get this error.

I get the same error when trying to use --replicate as well.

mk-table-sync --test --synctomaster --replicate=checksums.master
h=10.8.0.7,P=3306,u=pete,p=****
The slave is connected to 3318 but the master's port is 3306 at
/usr/bin/mk-table-sync line 4404.

I am running this version.
mk-table-sync --version
mk-table-sync  Ver 1.0.12 Distrib 2979 Changeset 2829

I get the same error on ubuntu 8.10 and centos 5.2

Original comment by rendhal...@gmail.com on 24 Feb 2009 at 2:36

GoogleCodeExporter commented 9 years ago
mk-table-sync discovers the master by inspecting SHOW SLAVE STATUS.  So it's 
working
-- it is then connecting to the same place the master is connecting.  But, this
sanity check fails when you have an SSH tunnel.

The sanity check is there for the purpose of throwing an error when an 
unreliable
means is used to best-guess discover masters and slaves of an instance.

Should we add a command-line parameter to permit skipping this check?  This is 
what I
would suggest doing.

Original comment by baron.schwartz on 24 Feb 2009 at 2:40

GoogleCodeExporter commented 9 years ago
For PCI compliancy reasons we can't have our master database accessible to the 
rest
of the internet.
So we have to use ssh tunnels to get to it.

I was just looking through the code to work out why it was complaining.
I think the command line switch is the best idea.
If i had some time to understand the code i might be able to work out how to 
add it
and submit a patch.

Original comment by rendhal...@gmail.com on 24 Feb 2009 at 3:47

GoogleCodeExporter commented 9 years ago
Any ideas or progress on this?

Original comment by rendhal...@gmail.com on 10 May 2009 at 11:02

GoogleCodeExporter commented 9 years ago
No progress on it -- the idea in comment 5 is sound, though.  I think it's the 
way to go.

Original comment by baron.schwartz on 15 May 2009 at 4:46

GoogleCodeExporter commented 9 years ago
If i get some time and work out a patch where would i send it?

Original comment by rendhal...@gmail.com on 17 May 2009 at 11:19

GoogleCodeExporter commented 9 years ago
You can attach it here, send it to the mailing list, or I'm happy to give you 
commit
access.  Follow the instructions at
http://code.google.com/p/maatkit/wiki/HowToPatchMaatkit to create a patch.  
Thanks!

Original comment by baron.schwartz on 18 May 2009 at 1:36

GoogleCodeExporter commented 9 years ago
Cool.
Will see how much time I get to do it.
Haven't been as busy at work so I may be able to fit it in sometime soon.

Original comment by rendhal...@gmail.com on 18 May 2009 at 3:32

GoogleCodeExporter commented 9 years ago
Were you able to find time to create a patch for this?

Original comment by dan...@percona.com on 5 Jun 2009 at 2:50

GoogleCodeExporter commented 9 years ago
Not as yet.
I have been busy at work.
I shall see what i can come up with next week.

Original comment by rendhal...@gmail.com on 5 Jun 2009 at 10:09

GoogleCodeExporter commented 9 years ago
Any news?

Original comment by vitaliy....@gmail.com on 12 Aug 2009 at 12:25

GoogleCodeExporter commented 9 years ago
rendhalver: by chance had time to patch this?  :-)  I can tell you where to 
start:
line 5593 in today's trunk copy:
      if ( $o->get('sync-to-master') ) {

         $dsns[0]->{dbh} = get_cxn($dsns[0], %common_modules);
         my $master = $ms->get_master_dsn($dsns[0]->{dbh},
            $dsns[0], $dp)
            or die "Can't determine master of "
               . $dp->as_string($dsns[0]);
         unshift @dsns, $master;

Basically, if one wanted to manually provide the master dsn for 
--sync-to-master,
then get_master_dsn() would be skipped and the provided master dsn (some @ARGV
element) would be unshifted onto @dsns instead.

Original comment by dan...@percona.com on 17 Aug 2009 at 3:36

GoogleCodeExporter commented 9 years ago
Or, right below, just don't call $ms->is_master_of($dsns[0]->{dbh}, 
$dsns[1]->{dbh});

Maybe:

  $ms->is_master_of($dsns[0]->{dbh}, $dsns[1]->{dbh}) if $o->get('check-master');

And then in the POD:

item --[no]check-master

default: yes

Check the master detected for L<"--sync-to-master">.

Original comment by dan...@percona.com on 17 Aug 2009 at 3:39

GoogleCodeExporter commented 9 years ago
Distractions ahoy!

Sorry for the lack of response guys.
(trouble with being a sysadmin is there is always something distracting going 
on)

Looks like there has been some change to the code since dan replied with where 
to do
the fixing. but i think i found the place.

Please see attached file.
I haven't done a test run yet but there doesn't seem to be any errors in the 
code,
this is mostly to see if i am doing the right thing.
:)

Original comment by rendhal...@gmail.com on 28 Aug 2009 at 4:47

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for the patch.  This has been applied in r4591.  There was one other 
place in
the code where --sync-to-master was used, so I applied this check there, too.  
So
--no-check-master should skip the master check anywhere --sync-to-master is 
used.

Original comment by dan...@percona.com on 28 Aug 2009 at 4:19

GoogleCodeExporter commented 9 years ago
:)
Cool.
I am glad it worked.

Original comment by rendhal...@gmail.com on 31 Aug 2009 at 9:57