读高性能MySQL（第4版）笔记19_云端和合规性

1. 如何构建数据库环境

1.1. 托管MySQL

1.2. VM上构建

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

2. 托管MySQL

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

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

2.3. Aurora MySQL

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

3. Aurora MySQL

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

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

3.3. Aurora中的所有托管解决方案都不兼容MySQL 8.0，而一些较旧的解决方案只兼容MySQL   5.6

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

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

3.6. Aurora无服务器（Serverless）

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

3.7. Aurora全局数据库（Global Database）

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

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

4. GCP Cloud SQL

4.1. Cloud SQL是GCP的托管MySQL的产品

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

4.3. SUPER权限被禁用

4.4. 插件加载功能被禁用

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

4.6. 原生的高可用性支持

4.7. 静止数据的原生加密

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

5. 虚拟机上的MySQL

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. Percona Toolkit包中的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. 合规性

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

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

6.3. GRC

6.3.1. 治理（Governance）

6.3.2. 风险管理（Risk management）

6.3.3. 合规性（Compliance）

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

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

6.6. 法规法案

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

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

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

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

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

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

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

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. 不建议使用触发器

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

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

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

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