mysql报错记录

MySQL主从配置后启动及复制报错解决

mysql在配置了主从之后,重启mysql,从节点启动报错2025-07-25T08:01:26.008289Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.42-0ubuntu0.24.04.1)  (Ubuntu).
2025-07-25T08:01:26.650123Z 0 [Warning] [MY-014067] [Server] Value for option 'ssl-cipher' contains cipher 'TLS_AES_256_GCM_SHA384' that is either blocked or deprecated (and will be removed in a future release). Please refer to the documentation for more details.
2025-07-25T08:01:26.650138Z 0 [Warning] [MY-014067] [Server] Value for option 'ssl-cipher' contains cipher 'TLS_CHACHA20_POLY1305_SHA256' that is either blocked or deprecated (and will be removed in a future release). Please refer to the documentation for more details.
2025-07-25T08:01:26.653120Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.42-0ubuntu0.24.04.1) starting as process 2185877
问题1:我启用了错误的配置ssl 

grep -r "ssl_session_cache_size" /etc/mysql/

用这个命令查看在配置中的ssl配置,然后删掉就可以启动了

问题2:从节点在加入后不能进行复制

在主节点查询下面这些信息

mysql> SHOW VARIABLES LIKE 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 1     |
+---------------+-------+
1 row in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.01 sec)

mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.00 sec)

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000013 |      157 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

然后查看从节点状态

mysql> show SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for source to send event
                  Master_Host: 47.77.194.174
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000013
          Read_Master_Log_Pos: 157
               Relay_Log_File: mysql-relay-bin.000025
                Relay_Log_Pos: 373
        Relay_Master_Log_File: mysql-bin.000006
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1007
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at source log mysql-bin.000006, end_log_pos 414. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 157
              Relay_Log_Space: 7173
              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: 0
                Last_IO_Error:
               Last_SQL_Errno: 1007
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at source log mysql-bin.000006, end_log_pos 414. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: 0a183393-5d59-11f0-9d1e-00163e0c02d2
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 250725 16:21:26
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:
1 row in set, 1 warning (0.00 sec)

在这里可以看到Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' at source log mysql-bin.000006, end_log_pos 414. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.

还有这个

这个就是主库的binlog变动了,从库找不到原来的了

然后在从库sql中执行,修改从库复制的主库的binlog

CHANGE MASTER TO
    ->   MASTER_LOG_FILE='mysql-bin.000013',
    ->   MASTER_LOG_POS=157;

start slave就可以了,有问题发在评论区

### MySQL 注入错误解决方案 在处理 MySQL 报错注入问题时,通常需要关注以下几个方面: #### 数据验证与清理 为了防止 SQL 注入攻击,应始终对用户输入的数据进行严格的验证和清理。可以使用参数化查询来确保传入的变量不会被解释为 SQL 语句的一部分[^1]。 ```javascript var mysql = require('mysql'); var connection = mysql.createConnection({ host : 'localhost', user : 'root', password : '', database : 'node_mysql_test' }); connection.connect(); // 使用 ? 占位符代替字符串拼接 var userId = 'someUserInput'; var queryStr = 'SELECT * FROM users WHERE id = ?'; connection.query(queryStr, [userId], function(error, results, fields){ if (error) throw error; }); ``` 上述代码通过 `?` 占位符传递参数,从而有效避免了潜在的 SQL 注入风险[^2]。 #### 设置合适的数据库权限 减少不必要的高权限分配给应用程序使用的账户也是防范措施之一。例如,在创建用于 Node.js 应用程序访问的数据库时,仅授予所需的最低限操作权限[^3]: ```sql CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'password'; GRANT SELECT, INSERT ON node_mysql_test.* TO 'app_user'@'localhost'; FLUSH PRIVILEGES; ``` 这样即使发生注入行为,恶意脚本也无法执行破坏性的命令如删除表或修改其他用户的记录等。 #### 版本兼容性考虑 如果遇到特定版本PHP中的函数不再支持的情况,则可能需要回滚到较旧但仍受支持的 PHP 版本来维持现有功能正常运行[^4]。然而对于现代开发环境而言,更推荐升级依赖库并调整相应语法以适配最新标准而不是降级整个平台。 另外值得注意的是,虽然这里讨论的重点是如何解决基于错误消息反馈机制下的SQL注入漏洞利用方法,但从长远来看加强整体安全策略才是根本之道——这包括但不限于定期更新软件栈组件、采用Web应用防火墙(WAF)过滤异常请求流量以及实施全面的日志审计制度等等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值