MySQL控制用户输错密码尝试次数

CoderJiang 2019-11-21

一、生产环境MySQL死锁如何监控及如何减少死锁发生的概率

首先,死锁并不是"锁死",死锁是由于两个或两个以上会话锁等待产生回路造成。

(一)死锁监控及处理方法

对于死锁的监控,各个版本都提供了innodb_print_all_deadlocks选项,打开该选项即会将死锁的日志输出到MySQL的错误日志当中,因此可以通过监控错误日志来达到监控死锁的目的。而对于MariaDB就更加简单了,MariaDB提供了Innodb_deadlocks的计数器,可以通过监控该计数器的增长来监控是否存在发生死锁。
假如线上出现死锁并且频率较高的话,务必要引起重视。由于死锁日志仅记录了最后引起死锁的两条SQL,因此并不能通过死锁日志立即定位
出死锁的原因,应当及时协同开发模拟出死锁过程,分析死锁产生原因,修改程序逻辑。

(二)如何降低死锁发生的概率

1、尽量使用短小事务,避免大事务
2、加FOR UPDATE/LOCK IN SHARE MODE锁时,最好降低事务隔离级别,例如用RC级别,降低死锁发生概率,也可以降低锁定粒度
3、事务中涉及多个表,或者涉及多行记录时,每个事务的操作顺序都要保持一致
4、通过索引优化SQL效率,降低死锁概率,避免全表扫描导致锁定所有数据
5、程序中应有事务失败检测及自动重复提交机制
6、高并发(秒杀)场景中,关闭innodb_deadlock_detect选项,降低死锁检测开销,提高并发效率

二、MongoDB有哪些优秀特性及适合的场景是什么

(一)优秀特性

1、实用性:面向类json富文档数据模型,对开发人员天然的友好
2、可用性:基于raft协议的自动高可用,轻松提供99.999%的可用性
3、扩展性:对分片集群的支持,为业务提供了友好的水平扩展
4、高性能:嵌套模型设计支持,减少了离散写,充分的物理内存利用率,避免了磁盘读
5、强压缩:WiredTiger引擎提供多种数据压缩策略,2~7倍的压缩比,大大节省了磁盘资源

(二)适合的场景

1、无多文档事务及多表关联查询需求
2、业务快速迭代,需求频繁变动行业
3、单集群并发过大无法支撑业务增长
4、数据量增长预期TB及以上存储需求
5、期望要求99.999%数据库高可用场景

三、GO语言对比其他的编程语言有何优势?实际生产环境如何取舍?

1、天生支持高并发,强一致语言,开发效率高兼具线上运行稳定安全
2、垃圾回收,不用关心内存分配与回收
3、强大的GMP模型,异步处理,支持高并发,小白也能轻松写出高并发代码

在实际生产环境中建议从如下几个方面考虑:

1、看业务场景,电商,大数据处理有现成的解决方案,不适合用。另外数学运算,cpu 密集型的也不用。
2、GO 擅长快速出业务原型,迭代开发效率高,初创公司强推
3、看公司开发的技术栈,如果差异较大,那么选用 GO的话上手更快,编程风格也能统一起来

四、一个大事务,有很多更新,现在被回滚了,但是又着急关机重启,怎么办才好?

1、首先,尽量避免在MySQL中执行大事务,因为大事务将会带来主从复制延迟等问题
2、大事务被kill,MySQL会自动进行回滚操作,通过show engine innodb status的TRANSACTIONS可以看到ROLLING BACK的事务,并且在回滚操作的时候仍然会持有相应的行锁
3、此时如果强行关闭MySQL,等到MySQL再次启动后,仍然会进行回滚动作
4、因此,为确保数据安全,建议还是耐心等待回滚完成以后再进行关机重启。关机重启前,可以调低innodb_max_dirty_pages_pct让脏页尽量刷新完毕,并且关闭innodb_fast_shutdown
5、假如实在没有办法需要关机的情况下,可以kill -9先关闭MySQL,前提是需要设置双一保证事务安全,否则可能丢更多事务数据。然后重启实例后innodb会自行crash recovery回滚之前的事务

PS, kill -9是高危操作,可能导致MySQL无法启动等不可预知的问题,请谨慎使用

五、如何降低UPDATE/DELETE时WHERE条件写错,或者压根没写WHERE条件带来的影响

1、尽量不要在线手工执行任何SQL命令,很容易出差错。线上直接执行SQL命令最好有第二检查人帮助确认
2、最好在测试环境执行SQL确认无误后,再到生产环境执行,或者提前在本地文本环境编辑好确认后再执行
3、建议打开sql_safe_updates选项,禁止没有WHERE条件或者不加LIMIT或者没有使用索引条件的UPDATE/DELETE命令被执行。也可以在用mysql客户端连接到服务器端时增加--safe-updates选项,例如:mysql --safe-updates -h xx -u xx
4、线上手动执行DML操作时,先开启事务模式,万一误操作可以回滚。例如:mysql> begin; update xxx; rollback;
5、通过DB管理平台执行DML操作,且在平台上增加对此类危险SQL的判断,直接拒绝危险SQL的执行
6、配置延迟从库,发现误删除数据后,从延迟从库快速恢复数据

六、MySQL如何控制用户输错密码尝试次数?

(一)插件辅助

从官方MySQL5.7.17开始,提供了CONNECTION_CONTROL和CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS插件,该插件又提供了connection_control_failed_connections_threshold、connection_control_min_connection_delay、connection_control_max_connection_delay三个参数

1、connection_control_failed_connections_threshold

该参数的含义是控制登陆失败多少次数后开启延迟登陆

2、connectioncontrolminconnectiondelay

该参数分别表示超过失败次数后每次重新连接最小的延迟时间,延迟计算公式为(当前失败总次数-失败阈
值)connectioncontrolminconnection_delay,因此错误尝试次数越多那么延迟时间也是越大

3、connection_control_max_connection_delay

最大延迟时间,超过该值后客户端可重新连接

4、安装插件后,可通过监控Connection_control_delay_generated状态值和INFORMATION_SCHEMA下的表

CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS来监控错误登录尝试次数

(二)错误日志监控

通过定时扫描MySQL错误日志来捕获账号密码错误次数,达到某个阈值以后可在系统防火墙屏蔽对应的主机ip达到屏蔽账号的目的(具体操作视情况而定)
如:错误日志会显示2019-05-10T13:04:41.232259Z 5 [Note] Access denied for user 'xucl'@'127.0.0.1' (using password: YES)

(三)其他说明

1、有些同学会误以为max_connection_errors能够控制错误密码的尝试次数,其实该参数只能防止如telnet类的端口探测,即记录协议握手错误的次数

2、最后,在生产环境一定要关注aborted_clients和aborted_connects的状态,发生异常必须及时关注

总结

以上所述是小编给大家介绍的MySQL控制用户输错密码尝试次数,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对安科网网站的支持!
如果你觉得本文对你有帮助,欢迎转载,烦请注明出处,谢谢!

相关推荐