用户 'repl_user'@'10.0.0.5' 的访问被拒绝但是 ip 10.0.0.5 来自哪里？
Access denied for user 'repl_user'@'10.0.0.5' but where ip 10.0.0.5 coming from?
在其中一个节点上，我设置了以下主节点：
CHANGE MASTER TO MASTER_HOST = '192.168.1.11', MASTER_USER = 'repl_user', MASTER_PASSWORD = 'repl123', MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 842;
这在过去有效，但现在我收到了这个奇怪的错误：
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 192.168.1.11
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 842
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 842
Relay_Log_Space: 249
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1698
Last_IO_Error: error connecting to master 'repl_user@192.168.1.11:3306' - retry-time: 60 maximum-retries: 86400 message: Access denied for user 'repl_user'@'10.0.0.5'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)
Slave状态显示：
Last_IO_Error: error connecting to master 'repl_user@192.168.1.11:3306' - retry-time: 60 maximum-retries: 86400 message: Access denied for user 'repl_user'@'10.0.0.5'
但是这个 'repl_user'@'10.0.0.5' 来自哪里？
我将此用户设置为：
MariaDB [(none)]> select user,host from mysql.user where user = 'repl_user';
+-----------+------+
| user | host |
+-----------+------+
| repl_user | % |
+-----------+------+
我在任何子网 10 上都没有任何节点。0.x.x .
错误的原因很简单：主主机将副本连接视为来自 10.0.0.5。
为什么会这样，我说不上来。一种明显的可能性是您的副本位于其自己的子网上 - 例如 192.168.7.0/24 - 即主服务器；并且通过 NAT（或某种 VPN）建立连接：
192.168.77.77 (your PC) --- 192.168.77.1 (local gateway)
|
|
10.0.0.5 (remote gateway)
|
192.168.1.11
要检查这一点，在副本机器上，运行:
traceroute -n 192.168.1.11
看看它告诉你什么。
确认复制机只有一个接口192.168.1.x，没有潜伏的10.0.0.x接口
然后，验证路由表以确保它们是正确的（如果它们不正确我会感到惊讶，但我已经看到 事情 发生了）。
如果没有用，我必须得出结论，技术上服务器与副本在同一网段，如您所说，但实际上 它是 而不是 ：它可能是，例如，在虚拟机环境中，或受防火墙保护。像这样的“地址克隆”设置非常不寻常，容易出现问题，但并非不可能：
192.168.1.77 (replica) ----- 192.168.1.11 (VM Host)
|
10.0.0.5 (internal dispatcher)
|
10.0.0.4 (MariaDB primary)
192.168.1.77 (replica) ----- 192.168.1.11 (Firewall external)
|
10.0.0.5 (Firewall internal)
|
192.168.1.11 (MariaDB primary)
这些设置甚至可能只能通过 hping 和仔细的跟踪路由（所谓的“firewalking”）等工具检测到（或不能检测到），假设没有非常小心地隐藏服务器寻址是它似乎是什么。例如，对 192.168.1.11 的端口 3306 的 TTL 测量可能会关闭，并显示数据包实际上通过了一两个不应该存在的额外节点。
然而，通过询问 NetOps 人员可以更容易地发现所有这些，这只是一种好奇心 - 你[=56= 重要的是] 正在使副本工作，为此，就目前情况而言，您需要授权 10.0.0.5。
===
比如我这里自己的PC是192.168.100.76。如果我连接到 192.168.200.233 上的主服务器，那将通过 192.168.200.x 子网的 NATting 网关发生，即 192.168.100.1（在 my 端) 和 192.168.200.1（在 other 一侧）。因此，主节点会看到我的副本请求来自 192.168.200.1.
如果我想让副本正常工作，那将是我必须授权的地址。
同理，需要从10.0.0.5授权replica.
是的，这意味着 我的 192.168.100.x 网络 中的任何 PC 都将被授权连接到该主机。要以不同的方式组织事情，必须更改网络路由。
例如，我可以请求 VPN 连接，以便我的 PC 收到 192.168.200.x 范围内的地址。数据包将被封装，发送到 192.168.100.1（显然），到达端口 1194 上的 192.168.200.1，然后“重新膨胀”并可能给定源地址 192.168.200.137。然后主要将“我”视为 192.168.200.137，我需要授权该地址，保留供我个人使用。
在其中一个节点上，我设置了以下主节点：
CHANGE MASTER TO MASTER_HOST = '192.168.1.11', MASTER_USER = 'repl_user', MASTER_PASSWORD = 'repl123', MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 842;
这在过去有效，但现在我收到了这个奇怪的错误：
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 192.168.1.11
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 842
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 842
Relay_Log_Space: 249
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1698
Last_IO_Error: error connecting to master 'repl_user@192.168.1.11:3306' - retry-time: 60 maximum-retries: 86400 message: Access denied for user 'repl_user'@'10.0.0.5'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)
Slave状态显示：
Last_IO_Error: error connecting to master 'repl_user@192.168.1.11:3306' - retry-time: 60 maximum-retries: 86400 message: Access denied for user 'repl_user'@'10.0.0.5'
但是这个 'repl_user'@'10.0.0.5' 来自哪里？
我将此用户设置为：
MariaDB [(none)]> select user,host from mysql.user where user = 'repl_user';
+-----------+------+
| user | host |
+-----------+------+
| repl_user | % |
+-----------+------+
我在任何子网 10 上都没有任何节点。0.x.x .
错误的原因很简单：主主机将副本连接视为来自 10.0.0.5。
为什么会这样，我说不上来。一种明显的可能性是您的副本位于其自己的子网上 - 例如 192.168.7.0/24 - 即主服务器；并且通过 NAT（或某种 VPN）建立连接：
192.168.77.77 (your PC) --- 192.168.77.1 (local gateway)
|
|
10.0.0.5 (remote gateway)
|
192.168.1.11
要检查这一点，在副本机器上，运行:
traceroute -n 192.168.1.11
看看它告诉你什么。
确认复制机只有一个接口192.168.1.x，没有潜伏的10.0.0.x接口
然后，验证路由表以确保它们是正确的（如果它们不正确我会感到惊讶，但我已经看到 事情 发生了）。
如果没有用，我必须得出结论，技术上服务器与副本在同一网段，如您所说，但实际上 它是 而不是 ：它可能是，例如，在虚拟机环境中，或受防火墙保护。像这样的“地址克隆”设置非常不寻常，容易出现问题，但并非不可能：
192.168.1.77 (replica) ----- 192.168.1.11 (VM Host)
|
10.0.0.5 (internal dispatcher)
|
10.0.0.4 (MariaDB primary)
192.168.1.77 (replica) ----- 192.168.1.11 (Firewall external)
|
10.0.0.5 (Firewall internal)
|
192.168.1.11 (MariaDB primary)
这些设置甚至可能只能通过 hping 和仔细的跟踪路由（所谓的“firewalking”）等工具检测到（或不能检测到），假设没有非常小心地隐藏服务器寻址是它似乎是什么。例如，对 192.168.1.11 的端口 3306 的 TTL 测量可能会关闭，并显示数据包实际上通过了一两个不应该存在的额外节点。
然而，通过询问 NetOps 人员可以更容易地发现所有这些，这只是一种好奇心 - 你[=56= 重要的是] 正在使副本工作，为此，就目前情况而言，您需要授权 10.0.0.5。
===
比如我这里自己的PC是192.168.100.76。如果我连接到 192.168.200.233 上的主服务器，那将通过 192.168.200.x 子网的 NATting 网关发生，即 192.168.100.1（在 my 端) 和 192.168.200.1（在 other 一侧）。因此，主节点会看到我的副本请求来自 192.168.200.1.
如果我想让副本正常工作，那将是我必须授权的地址。
同理，需要从10.0.0.5授权replica.
是的，这意味着 我的 192.168.100.x 网络 中的任何 PC 都将被授权连接到该主机。要以不同的方式组织事情，必须更改网络路由。
例如，我可以请求 VPN 连接，以便我的 PC 收到 192.168.200.x 范围内的地址。数据包将被封装，发送到 192.168.100.1（显然），到达端口 1194 上的 192.168.200.1，然后“重新膨胀”并可能给定源地址 192.168.200.137。然后主要将“我”视为 192.168.200.137，我需要授权该地址，保留供我个人使用。