技术头条(投递你的文章)     搜索本站     邮件订阅     微信号:IT技术博客大学习
您现在的位置首页 --> MySQL
    很多公司都禁止程序员在 SQL 中使用 JOIN,至于原因则出奇的一致:用 JOIN 慢。不过我从没见过谁来论证为什么用 JOIN 慢,结果这个人云亦云的结论越传越广,让我觉得是时候来讨论一下这个看似正确的结论了。
    从master上用xtrabackup物理备份到slave,启动实例后,应该再执行 mysql_upgrade 升级相关表结构,确保P_S(performanc_schema)、I_S(information_schema)以及 mysql 等几个系统库表结构都升级到最新版本。​
    MySQL 管理工具集 persona-toolkit。
    最近一段时间处理了较多锁的问题,包括锁等待导致业务连接堆积或超时,死锁导致业务失败等,这类问题对业务可能会造成严重的影响,没有处理经验的用户往往无从下手。下面将从整个数据库设计,开发,运维阶段介绍如何避免锁问题的发生,提供一些最佳实践供RDS的用户参考。
     互联网很危险,信息及数据安全很重要,SQL注入是最常见的入侵手段之一,其技术门槛低、成本低、收益大,颇受各层次的黑客们所青睐。 一般来说,SQL注入的手法是利用各种机会将恶意SQL代码添加到程序参数中,并最终被服务器端执行,造成不良后果。
    有时候,我们希望将 MySQL 的 relay log 多保留一段时间,比如用于高可用切换后的数据补齐,于是就会设置 relay_log_purge=0,禁止 SQL 线程在执行完一个 relay log 后自动将其删除。但是在官方文档关于这个设置有这么一句话: Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe. 究竟是什么样的风险呢?
    MySQL被运用于越来越多的业务中,在关键业务中对数据安全性的要求也更高,如何保证MySQL的数据安全?
    在mysql中limit可以实现快速分页,但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了,否则可能卡死你的服务器哦。
     对于一般进程,要让进程崩溃时能生成 core file 用于调试,只需要设置 rlimit 的 core file size > 0 即可。比如,用在 ulimit -c unlimited 时启动程序。 对 MySQL 来说,由于 core file 中会包含表空间的数据,所以默认情况下为了安全,mysqld 捕获了 SEGV 等信号,崩溃时并不会生成 core file,需要在 my.cnf 或启动参数中加上 core-file。 但是即使做到了以上两点,在 mysqld crash 时还是可能无法 core dump。还有一些系统参数会影响 core dump。
    问题:有位同学问我,在类似pt-osc场景下,需要将两个表名对调,怎么才能确保万无一失呢?
    问题:修改了 my.cnf 配置文件后,却不生效,这是怎么回事?
    一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发。简单说,在master上是并发模式(以InnoDB引擎为主)完成事务提交的,而在slave上,复制线程只有一个sql thread用于binlog的apply,所以难怪slave在高并发时会远落后master。
    想往一个表里添加一个自增列做主键,居然失败报告无法读取,这是怎么回事?
    有些人提倡,程序员在填充 SQL 模板时,应该更加小心。应对 SQL 注入问题,只是需要在编程方面多加小心。很明显,这种方式算不上解决方案。人们仍然在校验用户输入值方面出现错误,最终接受了带有恶意的用户输入值。换句话说,单凭我们所有人更努力地工作,是无法根本解决这种问题的。 真正的解决方案在于,SQL 语句本身的任意性,并要求所有现存不变量都符合任意的等价结构的规则。无需程序员的干预,就能自动完成。 攻击者不得不符合一种未知的、任意的 brainfuck 语法的规则。想要符合一组未知的规则,将是难以解决的问题。因此,攻击者通常无法得手。
    一般而言,我们在processlist结果中如果经常能看到某些SQL的话,至少可以说明这些SQL的频率很高,通常需要对这些SQL进行进一步优化。
    只读实例是目前RDS用户实现数据读写分离的一种常见架构,用户只需要将业务中的读请求分担到只读节点上,就可以缓解主库查询压力,同时也可以把一些OLAP的分析查询放到另外的只读节点上,减小复杂统计查询对主库的冲击。 由于RDS只读节点采用原生的MySQL Binlog复制技术,那么延迟必然会成为他成立之初就会存在的问题。延迟会导致只读节点与主库的数据出现不一致,进而可能造成业务上逻辑的混乱或者数据不正确;另外只读实例延迟同样也会触发binlog堆积,导致只读实例的空间迅速消耗完,这样会导致只读实例被锁定,锁定之后应用则无法完成读操作。 最近也收到了很多用户关于只读实例延迟的问题反馈,下面将会分析RDS只读实例出现延迟的几种常见场景,希望能够帮助用户理解和处理只读节点的延迟,更好地使用只读节点。
    MySQL Binlog Server:是利用某个工具,把线上活跃的库的日志拉取到本地进行备份。在MySQL 5.6以后,可以利用mysqlbinlog这个命令去把远程机器的日志备份到本地目录,从而达到增量或是日志安全方面的备份。 做好MySQL日志的备份,是数据安全的一个重要保证。以前通过写程序来实现,从MySQL 5.6出现以后,DBA同步有福了,不用写程序了。
    我们知道,MySQL里可以动态修改事务隔离级别,既可以加 GLOBAL 关键字直接修改全局的设置,也可以加 SESSION 关键字只修改当前会话的设置。那么,如果两个关键字都不加,会出现什么情况呢?
     一般而言,我们在processlist结果中如果经常能看到某些SQL的话,至少可以说明这些SQL的频率很高,通常需要对这些SQL进行进一步优化。 今天我们要说的是,在processlist中,看到哪些运行状态时要引起关注。
    本文主要写给那些立志成为MySQL DBA,以及正在学习MySQL的同行们,结合个人及业内其他同行的职业发展经历给大家一些参考,如何成为合格的MySQL DBA。
[共517篇文章][第1页/共26页][1][2][3][4][5][6][7][8][9][10][>|]
赞助商广告
© 2009 - 2017 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号