Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.5.32, 5.5(EOL)
Description
from
/usr/bin/mysqldump -u backup --all-databases --extended-insert --dump-slave=2 --master-data=2 --include-master-host-port --single-transaction --no-data
|
only the following replication position was recorded.
-- CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=4041, MASTER_LOG_FILE='mariadb-bin.000047', MASTER_LOG_POS=31738774;
|
Its useful too have both since in a backup scenario its unknown whether the dump is going to be use used to replace the master or configured as the new slave.
Attachments
Issue Links
- is part of
-
-
- Closed
-
- relates to
-
-
- Closed
-
- links to
Activity
| Labels | replication | replication upstream |
| Assignee | Elena Stepanova [ elenst ] |
ok. Thanks for the analysis - logged http://bugs.mysql.com/bug.php?id=69875
| Remote Link | This issue links to "mysqldump --master-data and --dump-slave are mutually exclusive (Web Link)" [ 12001 ] |
| Remote Link | This issue links to "mysqldump --master-data and --dump-slave are mutually exclusive (Web Link)" [ 12001 ] |
| Remote Link | This issue links to "Bug #69875 - mysqldump --master-data and --dump-slave are mutually exclusive (Web Link)" [ 12002 ] |
| Assignee | Elena Stepanova [ elenst ] |
| Description |
from /usr/bin/mysqldump -u backup --all-databases --extended-insert --dump-slave=2 --master-data=2 --include-master-host-port --single-transaction --no-data only the following replication position was recorded. -- CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=4041, MASTER_LOG_FILE='mariadb-bin.000047', MASTER_LOG_POS=31738774; Its useful too have both since in a backup scenario its unknown whether the dump is going to be use used to replace the master or configured as the new slave. |
from {noformat} /usr/bin/mysqldump -u backup --all-databases --extended-insert --dump-slave=2 --master-data=2 --include-master-host-port --single-transaction --no-data {noformat} only the following replication position was recorded. {noformat} -- CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=4041, MASTER_LOG_FILE='mariadb-bin.000047', MASTER_LOG_POS=31738774; {noformat} Its useful too have both since in a backup scenario its unknown whether the dump is going to be use used to replace the master or configured as the new slave. |
| Workflow | defaullt [ 28305 ] | MariaDB v2 [ 43967 ] |
| Summary | mysqldump --dump-slave=2 --master-data=2 doesn't record both | [PATCH] mysqldump --dump-slave=2 --master-data=2 doesn't record both |
| Component/s | OTHER [ 10125 ] | |
| Fix Version/s | 10.0 [ 16000 ] | |
| Affects Version/s | 5.5 [ 15800 ] | |
| Labels | replication upstream | replication upstream verified |
| Labels | replication upstream verified | patch replication upstream verified |
| Workflow | MariaDB v2 [ 43967 ] | MariaDB v3 [ 62044 ] |
| Labels | patch replication upstream verified | beginner-friendly patch replication upstream verified |
| Workflow | MariaDB v3 [ 62044 ] | MariaDB v4 [ 139526 ] |
| Fix Version/s | 10.0 [ 16000 ] |
Ok, I check the mysql code in branch 8.0 , but slave data and master data is still exclusive. So this suggested patch is not included.
In my opinion , when a user uses mysqldump, he need to know which role the machine is basiclly . And he still can manually STOP SLAVE SQL_THREAD or STOP SLAVE;
| Fix Version/s | 10.4 [ 22408 ] |
| Status | Open [ 1 ] | Confirmed [ 10101 ] |
| Assignee | Daniel Black [ danblack ] |
Can I get a review on https://github.com/MariaDB/server/pull/2701 please?
| Assignee | Daniel Black [ danblack ] | Brandon Nesterenko [ JIRAUSER48702 ] |
| Status | Confirmed [ 10101 ] | In Review [ 10002 ] |
| Link |
This issue relates to |
| Assignee | Brandon Nesterenko [ JIRAUSER48702 ] | Daniel Black [ danblack ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Assignee | Daniel Black [ danblack ] | Anel Husakovic [ anel ] |
| Status | Stalled [ 10000 ] | In Review [ 10002 ] |
| Assignee | Anel Husakovic [ anel ] | Daniel Black [ danblack ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| issue.field.resolutiondate | 2024-02-08 04:47:43.0 | 2024-02-08 04:47:43.462 |
| Component/s | Scripts & Clients [ 11002 ] | |
| Component/s | OTHER [ 10125 ] | |
| Fix Version/s | 10.5.25 [ 29626 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Fix Version/s | 10.6.18 [ 29627 ] | |
| Fix Version/s | 10.11.8 [ 29630 ] | |
| Fix Version/s | 11.0.6 [ 29628 ] | |
| Fix Version/s | 11.1.5 [ 29629 ] | |
| Fix Version/s | 11.2.4 [ 29631 ] | |
| Fix Version/s | 11.3.3 [ 29632 ] |
| Fix Version/s | 11.4.2 [ 29633 ] | |
| Fix Version/s | 11.3.3 [ 29632 ] |
Hi Daniel,
I agree, nothing in documentation suggests that these options are mutually exclusive, and comments in the code also don't explain why it's done this way, they only mention preserving master logs, but it's irrelevant to master_data:
/* We don't delete master logs if slave data option */
{ opt_lock_all_tables= !opt_single_transaction; opt_master_data= 0; opt_delete_master_logs= 0; }if (opt_slave_data)
if (opt_master_data)
{ opt_lock_all_tables= !opt_single_transaction; opt_slave_data= 0; }The fix is primitive unless there is a secret reason why it was done this way:
=== modified file 'client/mysqldump.c'
{ opt_lock_all_tables= !opt_single_transaction; - opt_master_data= 0; opt_delete_master_logs= 0; }— client/mysqldump.c 2013-04-12 08:48:21 +0000
+++ client/mysqldump.c 2013-07-30 11:17:22 +0000
@@ -950,7 +950,6 @@
if (opt_slave_data)
@@ -966,7 +965,6 @@
{ opt_lock_all_tables= !opt_single_transaction; - opt_slave_data= 0; }if (opt_master_data)
if (opt_single_transaction || opt_lock_all_tables)
lock_tables= 0;
However, since it comes from upstream, it would be good to (try to) get it fixed there. Are you willing to file a bug at bugs.mysql.com? I can do it on your behalf, but yours might have a better chance, besides it will be easier for you to track.