读高性能MySQL第4版笔记19云

1.1.托管MySQL

1.2.VM上构建

1.3.天下没有免费的午餐，每一个选择都伴随着一系列的权衡

2.1.服务商提供了一个可访问的数据库设置程序，而不需要用户深入了解MySQL的具体细节

2.2.使用托管MySQL将缺乏很多的可见性和控制能力

2.3.AuroraMySQL

2.4.谷歌云平台（GCP）提供了CloudSQL

3.1.AuroraMySQL是一个兼容MySQL的托管数据库

3.2.将计算和存储分开，这使二者可以更灵活地单独扩展

3.3.Aurora中的所有托管解决方案都不兼容MySQL8.0，而一些较旧的解决方案只兼容MySQL5.6

3.4.标准的Aurora产品是长期运行的计算实例，在其中选择一个实例类型

3.5.Aurora集群内的复制完全是Amazon专有的，而不是我们在OracleMySQL中所知道和使用的复制

3.6.Aurora无服务器（Serverless）

3.6.1.AuroraMySQL的无服务器服务移除了长期运行的计算程序，并利用亚马逊的无服务器平台为数据库的计算层提供服务

3.7.Aurora全局数据库（GlobalDatabase）

3.8.Aurora多主节点（Multi-Master）

3.8.1.多主节点是Aurora集群的一种特殊风格，可以同时在多个计算节点上接受写操作

4.1.CloudSQL是GCP的托管MySQL的产品

4.2.它运行的是社区版MySQL，但特别禁用了某些功能，以实现产品的多租户和可管理

4.3.SUPER权限被禁用

4.4.插件加载功能被禁用

4.5.一些客户端也被禁用了，如mysqldump和mysqlimport

4.6.原生的高可用性支持

4.7.静止数据的原生加密

4.8.使用多种方法实现灵活管理的升级

5.1.在虚拟机上运行MySQL就像在裸金属服务器上运行一样，你可以完整和彻底地控制所有的操作面

5.2.CPU

5.2.1.虚拟CPU，而不是物理CPU

5.2.2.vCPU数量的计数公式

5.2.2.1.（CPU核的数量×95%CPU总使用量）×2

5.2.2.2.建议将50%作为常规的使用率目标，最高可达到65%～70%

5.2.2.3.如果维持在70%或更高的CPU使用率，将可能会看到延迟增加，此时应该考虑添加更多的CPU

5.2.3.运行的是一个高流量的Web应用程序，则可能需要确保使用更新一代的芯片

5.3.内存

5.3.1.RAM可以极大地影响MySQL的性能

5.3.2.应为工作数据集选择最适合需求的机器规格，但错误的做法是RAM太多而不是不够

5.4.网络性能

5.4.1.如果有一个将读取大量数据的批处理进程，则你可能会发现在较小的机型上带宽已耗尽

5.5.选择正确的磁盘类型

5.5.1.高读密集型的工作负载将受益于更多的内存而不是磁盘性能，因为内存访问要快几个数量级

5.5.2.如果工作集大于InnoDB缓冲池，那么将总是需要到磁盘上读取一些数据

5.5.3.写密集型的工作负载总是会转移到磁盘上，这也是大多数人第一次看到磁盘瓶颈的地方

5.6.磁盘的连接类型

5.6.1.本地连接磁盘的好处是，其提供了令人难以置信的高性能和一致的吞吐量，但也很容易导致数据丢失

5.6.1.1.被视为仅用于短暂数据的磁盘

5.6.2.网络连接的磁盘可提供冗余和可靠性

5.6.2.1.网络连接的磁盘可能会遇到本地连接的磁盘不会出现的停顿

5.6.3.还可以使用磁盘快照技术让副本复制变得非常快，即使在许多TB级大小的磁盘上

5.6.3.1.可以让需要在副本可用之前赶上来的复制的延迟降到最低

5.7.SSD与HDD

5.7.1.SSD的启动速度比HDD快两到三倍

5.7.2.如果启动时间很重要，特别是在停机或重新启动的情况下，那么请始终使用SSD

5.8.IOPS和吞吐量

5.8.1.PerconaToolkit包中的pt-diskstats

5.9.只允许服务器恢复在线和复制，以让它自己自然地重新连接

5.9.1.使用SSD引导磁盘来允许尽可能快地重新启动。通常系统会在5分钟内恢复在线

5.9.2.禁止长达5分钟时间内的任何服务器宕机的告警通知，以使系统完全重启并恢复正常

5.9.3.如果源服务器重新启动，你可以编写一个选项来动态关闭read_only标志，从而让写入在没有人工干预的情况下继续进行

5.9.4.通过自动地向可能需要了解中断的团队或渠道发送邮件或消息，来让沟通最大化

5.10.建议将操作系统和MySQL数据分开

5.10.1.磁盘快照将仅限于MySQL数据，并且不包含任何操作系统信息

5.10.2.在使用网络连接的磁盘的情况下，可以轻松地断开磁盘的连接并重新连接到另一台机器

5.10.3.对于网络连接的磁盘，还可以升级或替换操作系统，而不必将数据重新复制到文件系统中

5.11.备份二进制日志

5.11.1.将二进制日志发送到一个存储桶中

5.11.2.在桶上设置生命周期控制，以便在一段确定的时间后自动清除旧文件

5.11.3.阻止在特定时间之前删除文件，或完全不允许删除

5.11.4.控制谁可以读取或删除这些数据对于维护安全的备份策略至关重要

5.11.5.建议允许所有数据库机器写入，但没有机器能够读取或删除。分别或同时控制受限账户、机器的读取和删除

5.12.自动扩展磁盘

5.12.1.对于网络连接的磁盘，需要为预分配的而不是已使用的空间付费

5.12.2.一种优化方法是将磁盘空间使用率目标提到更高的百分比

6.1.DBA的工作并不局限于在业务运行时管理这些数据，还需要帮助企业保护数据，并使数据符合法律要求，或获得对企业至关重要的监管认证

6.2.合规是一个涉及政策和控制的广泛领域，对每种政策和控制的解释也很多

6.3.GRC

6.3.1.治理（Governance）

6.3.2.风险管理（Riskmanagement）

6.3.3.合规性（Compliance）

6.4.控制是公司内部定义的流程和规则，用于减少意外风险结果发生的概率

6.5.合规性的构建是一个持续的过程，在需要的时候不容易“添加”

6.6.法规法案

6.6.1.服务组织控制类型2（SOC2）

6.6.2.年发布的萨班斯-奥克斯利法案（SOX）

6.6.3.支付卡行业数据安全标准（PCI-DSS）

6.6.4.年发布的《健康保险可携带性和责任法案》（HIPAA）

6.6.5.联邦风险和授权管理计划（FedRAMP）

6.6.6.通用数据保护条例（GDPR）是欧盟于年推出的

6.6.7.年，欧盟司法法院裁决了欧盟和Facebook爱尔兰分部之间的一桩案件。这项通常被称为SchremsII

6.7.不要共享用户

6.7.1.不要跨服务共享数据库凭据

6.8.不要在代码仓库中提交生产数据库凭据

6.8.1.一种常见的做法是在合并一个pull请求之前，扫描代码库寻找潜在的机密字符串（GitHub等代码仓库托管服务可以实现

6.9.确保密码始终以加密方式而不是以明文形式存储

6.9.1.机密信息的长度做了限制，如果想存储比数据库的用户和密码对更长的内容，可能会导致意外

6.10.区域的可用性

6.11.角色与数据分离

6.11.1.基于数据泄露将给企业或客户带来的风险等级对数据进行分离

6.12.出于合规性原因进行分片

6.13.独立的数据库用户

6.14.跟踪变更

6.14.1.很多合规性法规都附带了跟踪变更的控制措施

6.15.很多合规性法规都附带了跟踪变更的控制措施

6.16.⑩数据访问日志

6.16.1.要求维护特定数据集的变更日志或访问日志

6.16.2.Percona审计日志插件是Percona发行的MySQL分支的一部分，但是默认情况下没有安装或启用

6.17.⑾schema变更的版本控制

6.18.建议设置这样一个策略：“删除六个月内未连接过数据库的用户”。这一做法将有助于防止使用不需要的、现在已成为负担的访问

7.1.触发器会导致写性能下降，这会在最糟糕的时候对性能造成影响

7.2.触发器相当于在数据库中存储业务逻辑，这是不推荐的

7.3.在数据库中存储代码可能会绕过测试、转移和部署代码的任何过程。触发器可能意外地导致故障

7.4.触发器只能支持跟踪写入操作。无法扩展成可以跟踪读取访问的解决方案

转载请注明：http://www.aierlanlan.com/rzgz/9397.html