mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-26 00:34:18 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/rpl/r/rpl_show_slave_hosts.result

21 lines
531 B
Text
Raw Normal View History

Merged BUG#49978 from 5.1-bugteam to 5.5-bugteam.
2010-12-19 18:15:12 +01:00
include/master-slave.inc
[connection master]
MDEV-6720 - enable connection log in mysqltest by default
2016-03-25 20:51:22 +04:00
connect slave2,127.0.0.1,root,,test,$SLAVE_MYPORT2,;
connection slave2;
Bug#13963 SHOW SLAVE HOSTS is unreliable Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS when report-host option is set. If an expected slave does not appear in the list, nobody knows whether the slave does not connect or has started without the "report-host" option. The output also contains a strange field "Rpl_recovery_rank" which has never been implemented and the manual of MySQL5.4 declares that the field has been removed from MySQL5.4. This patch is done with these, According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed. Slaves will register themselves to master no matter if report_host option is set or not. When slaves are registering themselves, their Server_ids, report_host and other information are together sent to master. Sever_ids are never null and is unique in one replication group. Slaves always can be identified with different Server_ids no matter if report_host exists.
2009-10-20 14:30:15 +08:00
RESET SLAVE;
BUG #13963 Postfix
2009-10-23 10:19:50 +08:00
CHANGE MASTER TO master_host='127.0.0.1',master_port=MASTER_PORT,master_user='root';
Bug#13963 SHOW SLAVE HOSTS is unreliable Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS when report-host option is set. If an expected slave does not appear in the list, nobody knows whether the slave does not connect or has started without the "report-host" option. The output also contains a strange field "Rpl_recovery_rank" which has never been implemented and the manual of MySQL5.4 declares that the field has been removed from MySQL5.4. This patch is done with these, According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed. Slaves will register themselves to master no matter if report_host option is set or not. When slaves are registering themselves, their Server_ids, report_host and other information are together sent to master. Sever_ids are never null and is unique in one replication group. Slaves always can be identified with different Server_ids no matter if report_host exists.
2009-10-20 14:30:15 +08:00
START SLAVE IO_THREAD;
Merged BUG#49978 from 5.1-bugteam to 5.5-bugteam.
2010-12-19 18:15:12 +01:00
include/wait_for_slave_io_to_start.inc
MDEV-6720 - enable connection log in mysqltest by default
2016-03-25 20:51:22 +04:00
connection master;
Bug#13963 SHOW SLAVE HOSTS is unreliable Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS when report-host option is set. If an expected slave does not appear in the list, nobody knows whether the slave does not connect or has started without the "report-host" option. The output also contains a strange field "Rpl_recovery_rank" which has never been implemented and the manual of MySQL5.4 declares that the field has been removed from MySQL5.4. This patch is done with these, According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed. Slaves will register themselves to master no matter if report_host option is set or not. When slaves are registering themselves, their Server_ids, report_host and other information are together sent to master. Sever_ids are never null and is unique in one replication group. Slaves always can be identified with different Server_ids no matter if report_host exists.
2009-10-20 14:30:15 +08:00
SHOW SLAVE HOSTS;
Server_id Host Port Master_id
BUG#13333431 - INCORRECT DEFAULT PORT IN 'SHOW SLAVE HOSTS' OUTPUT Problem - The default port number shown in SHOW SLAVE HOSTS is always 3306 though the slave is actually listening on a different port number. This is a problem as the user can not be sure whether this port value can be trusted and so client trying to read replication topology can get confused. Fix - 3306 ceases to be the default value of report-port. Moreover report-port does not have a static default any longer. Instead we initialize report-port to 0 as the new default value and change it based on two checks : 1) If report_port is not set, the slave reports the port number its listening on. (i.e. if report-port is not set we get the actual value of the slave's port number). 2) If report-port is set, we show the value report-port is set to, as the slave's port number. mysql-test/include/show_slave_hosts.inc: A .inc file is added to use show slave hosts in the new test added. mysql-test/r/mysqld--help-notwin.result: Updated the result file to show the default value passed for report-port. mysql-test/suite/rpl/r/rpl_report_port.result: The result file for the new test that is added. mysql-test/suite/rpl/r/rpl_show_slave_hosts.result: Updated the result file to show the default value passed for report-port. mysql-test/suite/rpl/t/rpl_report_port-slave.opt: Option file for the new test added. mysql-test/suite/rpl/t/rpl_report_port.test: Added a test to check the correct functionality of report-port. We check this by running the replication twice. In the first run we do not set the value of report-port through the opt file and get the actual port number of the slave's port. We then restart the server with report-port set to some value (in this case 9000) and check the value reported for the slave's port number. mysql-test/suite/sys_vars/t/report_port_basic.test: Update the test file to show the value for report-port. It is replaced with SLAVE_PORT as the actual value of the report-port will change with each run. sql/mysqld.cc: Changed the value reported by report port : 1. If the value for report-port is not set we assign report-port to be the actual port number of the slave (mysqld_port). 2. If report-port is set we get the value set for the report-port. sql/sys_vars.cc: Passed 0 as the default value of the report-port.
2012-02-28 14:02:27 +05:30
3 slave2 SLAVE_PORT 1
BUG #13963 Postfix
2009-10-23 10:19:50 +08:00
2 SLAVE_PORT 1
MDEV-6720 - enable connection log in mysqltest by default
2016-03-25 20:51:22 +04:00
connection slave2;
BUG#12416700: RPL_SHOW_SLAVE_HOSTS FAILS SPORADICALLY (TIMEOUT IN WAIT_SHOW_CONDITION) There was a typo in the name of one of the parameters to the include file wait_show_condition. The parameter name was being set to "connection" instead of "condition". We fix this typo, improve one instruction in the test case and deploy parameter checks inside wait_show_condition.inc.
2011-05-10 12:41:09 +01:00
include/stop_slave_io.inc
MDEV-6720 - enable connection log in mysqltest by default
2016-03-25 20:51:22 +04:00
connection master;
Bug#13963 SHOW SLAVE HOSTS is unreliable Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS when report-host option is set. If an expected slave does not appear in the list, nobody knows whether the slave does not connect or has started without the "report-host" option. The output also contains a strange field "Rpl_recovery_rank" which has never been implemented and the manual of MySQL5.4 declares that the field has been removed from MySQL5.4. This patch is done with these, According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed. Slaves will register themselves to master no matter if report_host option is set or not. When slaves are registering themselves, their Server_ids, report_host and other information are together sent to master. Sever_ids are never null and is unique in one replication group. Slaves always can be identified with different Server_ids no matter if report_host exists.
2009-10-20 14:30:15 +08:00
SHOW SLAVE HOSTS;
Server_id Host Port Master_id
BUG #13963 Postfix
2009-10-23 10:19:50 +08:00
2 SLAVE_PORT 1
Merged BUG#49978 from 5.1-bugteam to 5.5-bugteam.
2010-12-19 18:15:12 +01:00
include/rpl_end.inc
Reference in a new issue Copy permalink