本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 数据层（亚马逊 Aurora 和亚马逊 ElastiCache） 通过将 WordPress 安装存储在分布式、可扩展、共享的网络文件系统上，并由 Amazon S3 提供静态资产，您可以将注意力集中在剩下的有状态组件：数据库。与存储层一样，数据库不应依赖于任何一台服务器，因此不能将其托管在其中一个 Web 服务器上。而应将 WordPress 数据库托管在亚马逊 Aurora 上。 [Amazon Aurora](https://aws.amazon.com/rds/aurora) 是一种与 My SQL 和 Postgre SQL 兼容的关系数据库，结合了高端商用数据库的性能和可用性，同时还具有开源数据库的简单性和成本效益。Aurora My 将数据库引擎与由专门构建的分布式存储系统紧密集成，来SQL提高我的SQL性能和可用性。SSD它具有容错能力和自我修复功能，可在三个可用区复制六个数据副本，可用性超过 99.99%，并且可以持续备份您在 Amazon S3 中的数据。Amazon Aurora 旨在自动检测数据库崩溃并重新启动，无需进行崩溃恢复或重新构建数据库缓存。 Amazon Aurora 提供了[多种实例类型](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html)，以适应不同的应用程序配置，包括内存优化型实例和可突发实例。要提高数据库的性能，您可以选择大型实例类型来提供更多CPU和内存资源。 Amazon Aurora 会自动处理主实例和 [Aurora 副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html)之间的故障转移，以便应用程序尽快恢复数据库操作而无需手动管理干预。失效转移到失效转移通常可在不到 30 秒的时间内完成。 创建至少一个 Aurora 副本后，使用集群终端节点连接到您的主实例，以便在主实例出现故障时您的应用程序能够自动进行故障转移。您可以跨三个可用区域创建多达 15 个低延迟只读副本。 随着数据库的扩展，数据库缓存也需要扩展。如前面的 “[数据库缓存](database-caching.md)” 部分所述， ElastiCache 它具有跨 ElastiCache 集群中的多个节点以及跨区域的多个可用区扩展缓存的功能，以提高可用性。在扩展 ElastiCache 集群时，请确保将缓存插件配置为使用配置终端节点进行连接，以便 WordPress 可以在添加新集群节点时使用它们，并在移除旧集群节点后停止使用它们。您还必须将 Web 服务器设置[为使用ElastiCache群集客户端](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html)，PHP并更新您的服务器AMI以存储此更改。