Closed GoogleCodeExporter closed 9 years ago
Are you saying that it never gets to the point of asking you for a password?
Or,
that once you enter the password, it goes on to do other work and then has an
error?
The --password option in mk-table-checksum is a vestigial tail back to the days
when
it only dealt with a single server. Now that DSN syntax is introduced, it's not
needed; you can add a 'p' part to any DSN.
Original comment by baron.schwartz
on 23 Oct 2008 at 10:55
It never gets to the point of asking for a password.
Thanks for the explanation on the --password option.
Original comment by eds...@gmail.com
on 23 Oct 2008 at 11:19
I'm looking into this.
Original comment by dan...@percona.com
on 25 Oct 2008 at 6:00
This problem might be specific to Windows/ActivePerl. On Linux it is working
for me:
perl -w mk-table-sync --execute --test --askpass --synctomaster h=127.1,P=12346
Enter password for 127.1:
# Syncing A=utf8,P=12346,h=127.1,p=...
# DELETE REPLACE INSERT UPDATE ALGORITHM DATABASE.TABLE
...
I'll have try this later on my Windows machine.
Original comment by dan...@percona.com
on 25 Oct 2008 at 6:16
I have reproduced this problem both on Linux and Windows:
perl -w mk-table-sync --execute --test --askpass --synctomaster localhost
Use of uninitialized value in concatenation (.) or string at mk-table-sync line
5037.
It only happens when the slave host is given like "localhost" and not as a DSN:
h=localhost
If you could please, re-try it on your machine and specify the slave host like
h=slavehost and let me know if that works.
According to the POD, just "slavehost" should work, so I'll look into why it is
not.
Original comment by dan...@percona.com
on 27 Oct 2008 at 4:44
Well this was an interesting problem, but it should be fixed now as of r2461.
Could
you please download this latest rev of mk-table-sync and tell me if it works
for you?
(It's working for me.)
I thought at first that DSNParser wasn't handling the bareword (localhost)
correctly.
It does handle barewords, but until now it did not handle barewords mixed with
explicit DSN parts; example: localhost,A=utf8
We were not specifying any extra, explicit DSN parts, but the script itself was
because of this option:
--utf8
negatable: yes; default: yes
Enable UTF-8 options in Perl and MySQL.
That's enabled by default which causes the script to append ",A=utf8" to
whatever
host/DSN is given on the command line, resulting in a mixed bareword + explicit
DSN
prop that the DSNParser module did not handle correctly.
This could have been a bigger problem if, instead of localhost, one gave
"host.domain.com" which would have become "host.domain.com,A=utf8" which,
ultimately,
would have become the wrong DSN: h=undef,P=undef,...,A=utf8. In other words:
DSNParser would clobber any bareword, losing any given bareword host except
'localhost' because h=undef is basically synonymous with 'localhost'.
And finally, this problem manifested itself with --askpass because the prompt
for
that prints the h DSN part, which was clobbered and therefore undefined. Now
that
DSNParser correctly sets the bareword host to the h DSN part, the --askpass has
something to print.
Fun stuff.
Original comment by dan...@percona.com
on 28 Oct 2008 at 4:08
First I tried specifying the slavehost like "h=slavehost" and it worked, then I
downloaded the latest rev and now just "slavehost" works as well.
Thanks!
Original comment by eds...@gmail.com
on 28 Oct 2008 at 10:43
You're welcome. Glad to hear that it is working as expected now.
Original comment by dan...@percona.com
on 29 Oct 2008 at 12:56
nevernow,
Have you downloaded and tried mk-table-sync r2461 or newer?
Original comment by dan...@percona.com
on 5 Nov 2008 at 1:47
Marking this issue as fixed. mk-table-sync Changelog updated.
Original comment by dan...@percona.com
on 12 Nov 2008 at 2:38
Original issue reported on code.google.com by
eds...@gmail.com
on 22 Oct 2008 at 12:12