| Bug #21490 | No warning issued for deprecated replication parameters | ||
|---|---|---|---|
| Submitted: | 7 Aug 2006 19:10 | Modified: | 9 Mar 2007 15:04 |
| Reporter: | Jonathan Miller | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.1.12 | OS: | Linux (Linux) |
| Assigned to: | Chuck Bell | CPU Architecture: | Any |
[7 Aug 2006 20:26]
Jonathan Miller
This is somewhat documented, but we should probably still issue a warning when reset slave has been done that change master may have been reset.
[19 Aug 2006 8:18]
Lars Thalmann
The replication options in the my.cnf file are deprecated and in the future (5.2 or later) all configuration of the slave will have to be done using CHANGE MASTER. For this bug report, I suggest we create a deprecation warning if any replication parameter is used in the my.cnf file (a replication parameter is anything that can be both configured using CHANGE MASTER and my.cnf). When this is done we close this bug report. Since RESET SLAVE is properly documented, this is not really a bug.
[21 Nov 2006 14:19]
Chuck Bell
I have a patch for this bug. The notes for the bug report state we should print a warning message for parameters in the my.cnf file, but what about command-line parameters? The solution I have identifies both parameters on the command-line and in the my.cnf file. Is this Ok or should I take another look at it and only issue the deprication warning if the parameters come from the my.cnf file?
patch:
===== mysqld.cc 1.590 vs edited =====
*** C:/DOCUME~1/Chuck/LOCALS~1/Temp/bk_mysqld.cc-1.590_a01556 2006-11-16 13:22:12 -05:00
--- edited/mysqld.cc 2006-11-16 13:19:50 -05:00
***************
*** 354,359 ****
--- 354,360 ----
my_bool opt_show_slave_auth_info, opt_sql_bin_update = 0;
my_bool opt_log_slave_updates= 0;
my_bool opt_innodb;
+ my_bool opt_slave_warning_issued = 0;
/*
Legacy global handlerton. These will be removed (please do not add more).
***************
*** 7490,7495 ****
--- 7491,7526 ----
case (int) OPT_STANDALONE: /* Dummy option for NT */
break;
#endif
+ /*
+ The following change issues a deprication warning if the slave
+ configuration is specified either in the my.cnf file or on
+ the command-line. See BUG#21490.
+ */
+ case OPT_MASTER_HOST:
+ case OPT_MASTER_USER:
+ case OPT_MASTER_PASSWORD:
+ case OPT_MASTER_PORT:
+ case OPT_MASTER_INFO_FILE:
+ case OPT_MASTER_CONNECT_RETRY:
+ case OPT_MASTER_RETRY_COUNT:
+ case OPT_MASTER_SSL:
+ case OPT_MASTER_SSL_KEY:
+ case OPT_MASTER_SSL_CERT:
+ case OPT_MASTER_SSL_CAPATH:
+ case OPT_MASTER_SSL_CIPHER:
+ case OPT_MASTER_SSL_CA:
+ if (!opt_slave_warning_issued) //only show the warning once
+ {
+ opt_slave_warning_issued = true;
+ sql_print_warning("Slave configuration using command-line parameters %s %s",
+ #if defined (__WIN__) || (_WIN64)
+ "or the my.ini file has been depricated. Please use",
+ #else
+ "or the my.cnf file has been depricated. Please use",
+ #endif
+ "CHANGE MASTER to setup the slave for replication.\n");
+ }
+ break;
case OPT_CONSOLE:
if (opt_console)
opt_error_log= 0; // Force logs to stdout
[21 Nov 2006 15:11]
Chuck Bell
The word "depricated" should be "deprecated" in previous comments. Patch has been corrected.
[19 Jan 2007 21:51]
Chuck Bell
Patch pushed on 18 January.
[8 Mar 2007 8:03]
Andrei Elkin
fixed 5.1.17-beta
[9 Mar 2007 15:04]
MC Brown
A note has been added to the 5.1.17 changelog.
Description: Hi, I changed my master mysql> CHANGE MASTER TO MASTER_HOST='n09.mysql.com'; Query OK, 0 rows affected (0.03 sec) Made sure it took mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: n09.mysql.com Yep, no problems. hmmm, lets restart, mysql_server restart Shutting down MySQL.... [ OK ] Starting MySQL [ OK ] mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Master_Host: n09.mysql.com Still there, okay I need to reset my slave side to be ready to go. mysql> reset slave; Query OK, 0 rows affected (1.10 sec) Okay, let me check one more time mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Master_Host: n08 hmmm, that should still be n09 :-( How to repeat: See above Suggested fix: When someone does a change master, that should be it. If they want to go back to the old master they should have to do another change master command.