Neo4j Aura 中断历史

1. 2026年10月26日 UTC 14:50investigating

   目前我们意识到,在试图下载数据库实例快照时,有一个问题正在影响客户使用Aura.

2. 2026年10月26日 UTC 15:09identified

   我们已查明了这一问题,目前正在努力部署这一解决办法.

3. 2026年10月26日 UTC 16:22identified

   目前,在部署之前,正在较低环境中测试该固定装置.

4. 2026年10月26日 UTC 17:43identified

   正在对固定装置进行测试,测试完成后将进行部署.

5. 2026年10月26日 UTC 19:14resolved

   我们的工程师已经成功部署一个固定装置,现在这个问题已经得到解决。 Azure上的Aura客户现在可以不发问题地下载数据库快照.

自动翻译自官方事件更新。

1. 2026年10月20日 UTC 07:35investigating

   我们目前正在调查影响GCP欧洲西部2区域的一个问题,这个问题正在影响一些业务,包括在该区域建立数据库实例.

2. 2026年10月20日 UTC 08:36investigating

   我们正在继续调查这一问题,同全球协商进程合作,以找到解决办法。 目前,一些业务,包括在该区域建立数据库的实例,仍然受到影响.

3. 2026年10月20日 UTC 09:15identified

   我们查明了目前影响欧洲西面客户的问题的根源。 详见全球气候方案现状网页https://status.cloud.google.com/incidents/Xs2XTHZAVC9YnafnPyzj。 目前,一些业务,包括在该区域建立数据库的实例,仍然受到影响.

4. 2026年10月20日 UTC 10:42identified

   我们目前正在采取补救行动来缓解这一问题。 在https://status.cloud.google.com/incidents/Xs2XTHAVC9YnafnPyzj的状态页面中,沿用了GCP的最新消息.

5. 2026年10月20日 UTC 12:38monitoring

   现在应恢复受影响的Aura服务的各种功能。 在考虑这一问题得到解决之前,我们将密切监测局势.

6. 2026年10月20日 UTC 14:06monitoring

   目前,我们正在通过全球合作进程继续监测局势,目前我们没有看到任何新问题.

7. 2026年10月20日 UTC 14:50resolved

   这件事已经解决了

自动翻译自官方事件更新。

1. 2026年10月13日 UTC 09:15investigating

   我们正在调查一个影响 Aura Console 的度量衡的问题,并通过度量终点.

2. 2026年10月13日 UTC 10:13identified

   我们确认,与云服务供应商有关的问题正在影响目前的局势。 我们已与云服务提供方一起启动了一个支助案件,一旦我们掌握了更多细节,我们将进一步更新.

3. 2026年10月13日 UTC 11:01monitoring

   我们认为,云服务供应商问题已经解决,因为我们不再从内部系统看到问题。 我们将继续监测局势,同时等待云服务供应商的确认.

4. 2026年10月13日 UTC 12:08resolved

   我们从云服务供应商那里得到确认,该问题现已得到全面解决.

5. 2026年10月16日 UTC 17:06postmortem

   GCP 欧洲西部发送度量衡时的误差 发生了什么事? 2026年10月13日星期二协调世界时08:54,GCP Europe-West 1中实例的度量衡停止交付,无法被读取. 原因是Google Cloud方面的一个问题,其监测服务能力下降导致有效请求被错误地拒绝。 Metrics UTC10:49在Google Cloud应用了固定后恢复正常,一旦Google Cloud确认完全解析,我们在UTC12:08解决了事件. Instances)在整个活动中仍然可用,对查询性能或数据完整性没有影响. 仅影响到衡量的能见度。 服务如何受到影响? 客户在实例度量中看到一些短短的空白: * 控制系数:** GCP Europe-west 1 中的例子可能显示在事件窗口中存在不完整或缺失的度量数据. * 云监测一体化(CMI):** 从本区域传送给你们自己的监测系统的计量标准也可能存在差距。 该区域并非所有事件都受到影响,而其他云提供者和区域则未受影响。 事件期间产生的计量数据没有记录,因此,受影响事件的历史图表中将保留这一差距。 我们现在在做什么? 校对:Soup * 区域复原力:** 我们正在评估跨区域的路线,以便衡量交通量能够向健康区域倾斜。 * 路线:** 我们正在探索在云层中选择将\(Console和CMI\)的路由改为\(摄入)

自动翻译自官方事件更新。

1. 2026年10月8日 UTC 14:58investigating

   我们正在调查一个在Aura Console 和通过度量终点的度量衡问题.

2. 2026年10月8日 UTC 15:36identified

   我们继续调查其根源。 问题仅限于我们中心1的客户 Aura 实例正在运行,没有操作受到影响.

3. 2026年10月8日 UTC 16:30identified

   我们正在与云服务供应商合作,调查这一问题的性质。 我们的检查证实,只有一部分在中央1地区运行的客户受到影响.

4. 2026年10月8日 UTC 18:41identified

   我们继续与云服务供应商合作,寻求解决办法.

5. 2026年10月8日 UTC 19:11resolved

   这一事件现在已经得到解决,衡量标准现在应该正常运行.

6. 2026年10月16日 UTC 17:04postmortem

   QQ 发送 GCP 我们- Central 1** 的度量衡时的误差 发生了什么事? 在协调世界时2026年10月8日星期四14:05,GCP us-Central1的一些情况中的度量衡停止交付. 原因是Google Cloud方面错误地拒绝了有效的度量标准请求。 在协调世界时18:48Google Cloud应用了固定器后,量子交付于协调世界时18:00恢复,我们在协调世界时18:48解决了事件. Instances)在整个活动中仍然可用,对查询性能或数据完整性没有影响. 只有衡量标准能见度暂时受到影响。 服务如何受到影响? 客户在实例度量中看到空白: * 控制系数:** GCP us-Central 1 中的例子可能显示在事件窗口中存在不完整或缺失的度量数据. * 云监测一体化(CMI):** 从本区域传送给你们自己的监测系统的计量标准也可能存在差距。 并非该区域所有情况都受到影响,其他云提供方和区域未受影响。 我们现在在做什么? 但我们正在采取措施, 以更快地捕捉和回应类似事件: * 使用度量交货错误:** 我们正在增加关于公尺转发出错率的提示,因此供应商方的出错被提前发现,并区别于例行漏洞. * 持续监测:** 我们将继续用Google Cloud监测该地区

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 09:22investigating

   我们正在调查一个问题,尽管备份成功完成,但快照下载正在返回空白垃圾堆。 通过Aura控制台或API从快照恢复,据信不会受到影响,我们正在核实这一点。 一旦掌握更多信息,我们将立即分享最新情况.

2. 2026年10月6日 UTC 10:43investigating

   我们正在继续调查这一问题。 恢复行动不因这一问题而受到影响.

3. 2026年10月6日 UTC 13:41investigating

   我们正在继续调查这一问题.

4. 2026年10月6日 UTC 13:41investigating

   我们正在继续调查这个问题。

5. 2026年10月6日 UTC 15:19resolved

   已部署一个固定装置;快照下载现在包含适当的数据.

6. 2026年10月26日 UTC 08:58postmortem

   发生了什么事 在Fri, 2026年9月18日 UTC下午14点33分, 我们发现, Azure 上主播的 Aura 实例的快照下载正在返回大约24KB的文件, 而不是预期的多基加比特大小。 存储在Azure中的基本备份是正确大小的,但控制台中的下载路径是服务于近空文件. 其根源是部署期间发生的Azure证书问题,使备份数据无法提供下载。 在Mon, 21 September 2026 10:31 UTC上部署了一个初步的固定装置,恢复正确的下载大小. 然而,同样的证书问题在Tue上再现,2026年10月06日08:20 UTC再次产生所有Azure级的空白快照下载. 我们的工程小组查明了重犯,将其与同一根源联系起来,对生产工作进行了有针对性的认证,并核实下载量恢复到预期规模。 9月18日我们没有登入状态网页,因为少数顾客受到影响,我们直接与他们合作. 我们在协调世界时10月6日09:22发布, 大约在复发开始一小时后, # 服务如何受到影响 AuraDS专业和企业、AuraDB专业、业务关键和虚拟专用云的下载受到影响。 * 快照下载返回无法使用的文件。 当客户从控制台上下载快照时,他们收到了大约24KB的文件,而不是实际的备份数据,其大小可能是几千兆字节. 这使下载的快照无法用于离线恢复或迁移目的。 * 备份本身没有丢失。 储存在Azure的原始备份文物完好无损,尺寸正确. 这个问题严格在下载路径中,而不是在备份抓取或存储过程中. * 通过控制台恢复的工作没有受到影响。 平台中恢复操作\(而不是下载一个垃圾文件\)继续运行,因为他们直接访问备份数据而不是通过受影响的下载路径. # 我们现在所做的 我们已采取多步骤来解决这一问题并实施了保障措施来防止再次发生。 * 已部署证书固定装置。 我们纠正了制作中的Azure证书问题,它立即恢复了所有受影响事件的快照下载。 * 防止无意的证书轮换。 已经提交了代码更改,以恢复每次部署时触发Azure证书旋转的逻辑。 这保证了今后的部署不会无意中使现有证书失效,而这是造成最初事件及其再起的机制。 * 持续监测。 我们正在监控Azure快照的下载 以证实它们保持稳定 我们要求受影响的客户核实他们的下载现在还原预期的文件大小。 这些变化既解决了直接症状,也解决了使问题再次发生的潜在部署行为

自动翻译自官方事件更新。

1. 2026年10月6日 UTC 08:07identified

   我们在试图从AuraDS的快照中恢复过来时发现了一个问题。 我们准备就绪 很快就会部署这个 与此同时,你可以从备份中恢复.

2. 2026年10月6日 UTC 09:07identified

   我们已明确查明了根源,并正在继续努力解决这个问题.

3. 2026年10月6日 UTC 10:03identified

   我们继续努力解决这个问题.

4. 2026年10月6日 UTC 12:14identified

   正在部署一个固定装置,不久将向受影响的客户推出.

5. 2026年10月6日 UTC 13:35monitoring

   固定装置正在推出,受影响的客户应看到功能逐步得到恢复.

6. 2026年10月6日 UTC 14:04resolved

   我们把所有的客户都安排好了.

7. 2026年10月26日 UTC 08:51postmortem

   发生了什么事 Neo4j Aura快照的一个中央管理组件的软件缺陷恢复了AWS上托管的AuraDS专业和AuraDS Enterprise实例的失败. 当请求恢复时,系统使用不正确的资源类型查看了实例,并返回了错误。 事件于协调世界时2026年10月5日星期一21:52宣布. 我们的工程团队查明了根源,开发并验证了固定装置,并于协调世界时2026年10月06日星期二13:37投入生产. # 服务如何受到影响 其影响范围旨在为AuraDS专业和AuraDS Entertainment实例描述恢复操作。 在发行期间,受影响的客户无法通过Aura Console或Aura API恢复快照。 * 恢复返回错误的尝试,中断依赖于快照恢复的工作流程。 * 在整个活动期间仍有一些实例。 数据完整性没有受到影响。 完全和出口后援的恢复工作仍然可以进行。 # 我们现在所做的 *我们修复了Aura管理层的缺陷,影响了AuraDS专业和AuraDS Entertainment的快照恢复并部署到生产中. * 部署管道优化:在这一事件中,部署管道由于连续试验实例的产生而耗时超过理想。 我们评价了并行的试验实例创建,以减少关键推出期间的等待时间。 这一改进旨在缩短对未来事故进行验证和运送固定装置所需的时间,减少对客户的影响

自动翻译自官方事件更新。

1. 2026年9月17日 UTC 16:46investigating

   目前我们意识到一个正在影响某些数据库操作的问题,例如使用Aura on Azure为客户创建,删除,克隆.

2. 2026年9月17日 UTC 17:11identified

   我们已查明这一问题并正努力寻求解决办法。 此时,某些数据库操作,如仅使用Azure上的Neo4j Aura为客户创建,删除和克隆,继续受到影响.

3. 2026年9月17日 UTC 19:06monitoring

   所有受影响的环境都安装了固定装置。 我们将监测局势,以确保解决问题.

4. 2026年9月17日 UTC 19:55resolved

   在使用固定装置后,我们监测了受影响的事例、操作参数和错误。 这一事件现在已经得到解决。 验尸工作一旦完成.

5. 2026年10月16日 UTC 16:23postmortem

   发生了什么事 2026年9月17日星期四协调世界时13:52,同时行动之间的部署时间冲突导致一个核心的Aura组件使用认证与Azure托管的基础设施的证书被移除. 由于已存在的认证符已过期,该组件开始返回Azure上托管的一些Aura事件的错误,影响了某些数据库操作. 我们追踪了丢失的证书的错误,创造了一个新的证书,安全地储存了它,并对受影响的部分进行了滚动部署,在协调世界时18:39完成. 少数在停用期间正在执行的数据库创建请求处于不完整状态,需要人工补救。 这在协调世界时19:48完成,事件标注于协调世界时19:55解决. # 服务如何受到影响 影响仅限于Azure岛的Aura事件。 其他云提供者没有受到影响。 * ** 数据库业务:** 客户无法在Azure事件窗口期间进行某些数据库操作,例如创建、删除和克隆。 少数正在进行中的创造物被卡住并人工回收。 * ** 管理层的能见度:** 在Aura Console,一些Azure主持的情况暂时看不到或无法管理。 * ** 计量差距:** 一些Azure事件的计量端点返回了断断续续的错误,在受影响期间的计量数据方面留下了短暂的空白。 此数据将不会被回填 。 已经运行的Azure案仍然可用,并继续正常地为工作量服务。 # 我们现在所做的 我们正采取以下步骤来帮助防止再次发生这种情况并改进我们的对策: ***耳机探测和通信:** 我们将改进监测和警报工作,并评估自动化的证书检查,从而发现问题并尽早通知客户。 * ** 从不完整的数据库创建中恢复:** 我们将修复一个缺陷,如果一个基础设施呼叫部分中断, 数据库的创建就会被困住, 因此系统会自行恢复。 ** 核证审查:** 我们将审查这一组件如何通过云提供商认证,去除单一的故障点并减少此类冲突再起的风险.

自动翻译自官方事件更新。

1. 2026年9月16日 UTC 08:50identified

   我们支助门户的服务提供者正面临一些停用问题 -- -- 见https://status.salesforce.com/products/Salesforce Services。 如果您遇到提交新支持案件的问题,请发送电子邮件支持@neo4j.com

2. 2026年9月16日 UTC 09:16identified

   我们的支助门户提供者仍在努力解决这一问题。 详见https://status.salesforce.com/incidents/20004433

3. 2026年9月16日 UTC 10:11identified

   我们的支助门户提供者继续努力解决这一问题。 详见https://status.salesforce.com/incidents/20004433

4. 2026年9月16日 UTC 11:30monitoring

   正在推出一个固定办法,随着时间的推移,门户应减少受到错误的影响。 详见https://status.salesforce.com/incidents/20004433

5. 2026年9月16日 UTC 12:29monitoring

   我们的支助门户提供者继续推出一个解决方案.

6. 2026年9月16日 UTC 14:31resolved

   已安装了固定装置,现在应恢复所有功能.

自动翻译自官方事件更新。

1. 2026年9月9日 UTC 12:31investigating

   我们正在调查一个影响Aura控制台控制台的问题

2. 2026年9月9日 UTC 12:54identified

   我们已确定了问题的根源,并正在研究解决办法.

3. 2026年9月9日 UTC 13:10identified

   我们继续努力解决这一问题.

4. 2026年9月9日 UTC 13:26identified

   我们已取得良好进展并正在恢复有问题的部分.

5. 2026年9月9日 UTC 13:36monitoring

   我们已经部署一个固定装置,受影响的服务正在恢复.

6. 2026年9月9日 UTC 13:39resolved

   所有受影响的部件现已完全恢复.

自动翻译自官方事件更新。

1. 2026年9月3日 UTC 16:43investigating

   我们目前正在调查这一问题.

2. 2026年9月4日 UTC 10:23identified

   已经查明了问题,仍有一些实例,目前正在审查为解决受影响的实例而采取的步骤.

3. 2026年9月4日 UTC 15:36resolved

   所有情况都可用,为了解决剩余的少量情况,采取了人工步骤来解除封锁.

自动翻译自官方事件更新。

1. 2026年8月20日 UTC 15:49investigating

   我们的小组已查明一个问题,即收集奥拉事件的衡量标准。 这将影响衡量的能见度和转发。 我们目前正在调查这一问题.

2. 2026年8月20日 UTC 16:48investigating

   我们继续调查奥拉度量衡问题.

3. 2026年8月20日 UTC 19:10resolved

   自上次更新以来,调查继续进行。 问题已经确定,我们监测这项服务从退化中恢复过来。 我们确认这个问题现已得到解决.

4. 2026年9月17日 UTC 10:09postmortem

   发生了什么事 2026年8月20日 UTC下午14:58分,我们的计量摄入管在将数据发往Google Montroled Prometheus\(GMP\)时,开始经历高发的出口故障. 其根本原因是Google Cloud平台在 " us-west1 " 地区发生的服务事故,事故中断了我们收集度量衡基础设施所使用的出口路径。 因此,在生产环境的分集中,计量输出队列开始形成。 失败主要表现为在试图向全球监测方案提供计量数据时出现网络超时,防止受影响集群的正常摄入。 我们的工程小组查明了受影响的系统在地理上的集中情况——跨越AWS`us-West-2'、Google Cloud`us-West1'和Azure`Westus2'——所有这些系统都通过俄勒冈地区的基础设施。 GCP区域事件被Google缓解后,出口出错平息并开始排队. # 服务如何受到影响 影响仅限于对一小类Aura环境的**度能见度**。 大约45个客户环境受到影响,这意味着在事故窗口期间,数据库的计量数据没有被输入我们的监测平台。 受影响最大的区域是AWS " us-West-2 " ,在Google Cloud "us-West1 " 和Azure " Westus2 " 中产生了额外影响。 在这些地区有数据库的客户可能在其衡量仪表板和监测事件期间的数据方面出现空白。 核心数据库业务——包括阅读、写作和可用性——**没有受到影响;只有业绩指标的收集和能见度受到干扰。 一旦谷歌缓解了潜在的区域问题,计量摄入量恢复了,并处理了排队数据的积压. # 我们现在所做的 我们对这一事件进行了彻底审查,并正在采取以下步骤来提高我们的复原力和应对能力: * ** 改进的可观察性仪表板**: 我们正在加强我们的指标出口者仪表板,以便更明确、更快地显示队列保健和出口出错率,从而能更快地发现和诊断出类似的问题。 * ** 改进警报汇总**: 我们正在实行自动警报分组,以便更好地将影响多个集群的区域事件作为单一相关事件来出现,并给予适当重视和重视。 * ** 主动提醒摄入出错率:** 我们正在增加专门的警报,即向高升的GMP摄取出错率开火,使我们的团队在出口商排队到达能力之前提前发出信号. 这些改进旨在缩短检测时间,简化事件分类,并加强我们针对未来上游供应商中断的计量管道.

自动翻译自官方事件更新。

1. 2026年8月5日 UTC 17:31investigating

   We have identified an issue currently that could result in unexpected query failures when using the trim() Cypher function. Investigations into the cause are in progress.

2. 2026年8月5日 UTC 19:27identified

   We have found the issue and are working on a fix. A small percentatge of queries using trim may still err. VDC customers with databases set to highest are not impacted at all unless they pause and start their instances.

3. 2026年8月6日 UTC 00:58identified

   We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.

4. 2026年8月6日 UTC 07:13identified

   We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances

5. 2026年8月6日 UTC 11:17identified

   We continue to validate the fix for the trim() Cypher function. Further updates will be provided before we begin deploying it to Aura instances.

6. 2026年8月6日 UTC 14:54identified

   The fix for the trim() Cypher function is undergoing testing and validation before deployment. Further updates will be provided before we begin deploying it to Aura instances.

7. 2026年8月7日 UTC 01:15identified

   Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.

8. 2026年8月7日 UTC 01:16identified

   We are actively working on addressing the issue. The fix for the trim() Cypher function is undergoing testing and validation currently before deployment. Further updates will be provided before we begin deploying it to Aura instances.

9. 2026年8月7日 UTC 09:44identified

   The fix to the trim() Cypher function has passed testing and validation and is now being deployed.

10. 2026年8月7日 UTC 13:49monitoring

    The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.

11. 2026年8月7日 UTC 15:34resolved

    We have monitored the fix and found the service to be stable. This incident is now considered resolved.

1. 2026年7月23日 UTC 10:52investigating

   我们现在正在调查一个问题.

2. 2026年7月23日 UTC 11:08investigating

   我们正与工程小组合作,目前调查工作正在取得进展.

3. 2026年7月23日 UTC 11:24investigating

   我们正在与工程小组合作,并继续在目前的调查中取得进展.

4. 2026年7月23日 UTC 11:38identified

   我们已查明造成目前问题的原因,并正在积极努力解决该问题.

5. 2026年7月23日 UTC 11:53identified

   我们正在部署解决办法的第一部分,并正在继续积极推动全面解决办法。 我们期待一个ETA 大约1小时后.

6. 2026年7月23日 UTC 12:11identified

   我们已查明了受到影响的几类事件,并继续在这个时候采取补救措施.

7. 2026年7月23日 UTC 12:32identified

   我们已部署一个配置固定装置,目前正在努力解决受影响的子事件.

8. 2026年7月23日 UTC 12:49identified

   随着配置固定的部署,我们正在继续解决仍然受到影响的一些情况.

9. 2026年7月23日 UTC 14:07identified

   我们正在继续解决仍然受到影响的一些情况.

10. 2026年7月23日 UTC 14:27identified

    我们继续解决仍然受到影响的一些情况.

11. 2026年7月23日 UTC 14:44monitoring

    我们继续解决仍然受到影响的一些情况.

12. 2026年7月23日 UTC 15:03monitoring

    AURADB虚拟专用云和AURADB Business Critical 现在应该全部固定. 我们继续解决那些仍然影响AuraDB专业和自由的案例.

13. 2026年7月23日 UTC 15:29monitoring

    我们继续解决那些仍然影响AuraDB专业和自由的案例.

14. 2026年7月23日 UTC 15:57monitoring

    我们继续解决仍然影响到AuraDB专业和自由的一些案例.

15. 2026年7月23日 UTC 16:32monitoring

    我们继续解决仍然对AuraDB专业和自由公司产生影响的少数案例

16. 2026年7月23日 UTC 17:01monitoring

    我们继续处理一些仍然影响到AuraDB专业和自由的事例

17. 2026年7月23日 UTC 17:31monitoring

    我们继续处理仍然在AuraDB专业和自由级别下受到影响的少数案例.

18. 2026年7月23日 UTC 18:07monitoring

    我们在所有AuraDB专业案例中都讨论了这一问题。 Aura Free仍然可以受到影响. 我们将继续监测和修复剩余的数据库.

19. 2026年7月23日 UTC 19:39monitoring

    我们继续处理仍然受到影响的一小部分自由事件.

20. 2026年7月24日 UTC 06:00monitoring

    我们正在继续密切监测局势,以处理任何进一步的问题.

21. 2026年7月24日 UTC 08:30monitoring

    我们正在继续监测任何其他问题.

22. 2026年7月24日 UTC 12:59monitoring

    所有已查明的事例都已得到纠正并继续监测。 就任何其他问题与客户联系.

23. 2026年7月24日 UTC 15:56resolved

    所有解决办法都已部署,问题现已标为已解决.

24. 2026年7月29日 UTC 21:58postmortem

    发生了什么事? 周四,Jul 23,2026 10:33 UTC向Aura部署了一个配置变化,无意中改变了数据库实例内存分配的计算方式. 因此,一个子集事件接收到的内存不足,导致一些数据库事件无法使用或无法完成更新. 被调整的内存分配导致记忆外状况,导致数据库事件由于内存资源不足而再三重启,或成为被卡住的更新. 这个问题影响到多个云供应商和多级产品。 问题一经确定,我们立即恢复了配置变化,防止其他任何情况收到不正确的配置。 在协调世界时2026年7月23日11:56周四之前,已部署已更正的配置投产. 然而,已经收到错误配置的数据库实例需要个人采取恢复行动,然后才能恢复正常运作。 至协调世界时2026年7月23日星期四17:59,所有已知的影响客户的数据库事件被找回. 监控持续到次日,事件于协调世界时2026年7月24日(Jul 24,2026年16:30)周五完全解决. ** 服务是如何受到影响的** 主要对客户的影响是,若干AuraDB数据库实例无法使用或进入了退化状态。 受影响的情况无法完成例行的软件更新,在某些情况下,由于内存分配不足,一再重启。 * ** 服务可用性:** 客户的影响因服务级别而异。 无法提供高可用性的AuraDB专业案例,其服务中断程度最大,一个子集无法使用,无法处理读取或写作。 对于受影响的AuraDB Business Critical and Virtual District Cloud \(VDC\)案例,影响一般限于暂时丧失容错能力,同时维持服务可用性. 在少数情况下,商业临界和VDC也变得无法使用。 * ** Stuck最新消息**: 其他实例仍然可用,但被卡在"更新"状态下,这阻碍了客户启动的操作,如大小调整或配置改变等. * ** 跨平台范围**: 这一影响涉及所有三个支助云供应商和多个区域,影响到全球客户。 客户支助案件被提起,我们的小组按优先顺序对受影响情况进行分类和人工恢复。 大多数AuraDB项目继续正常运行。 通过恢复每个受影响案例的配置和有针对性的人工恢复,充分减轻了客户的影响。 我们现在在做什么? 我们对这一事件进行了透彻的分析,并确定了以下行动: * ** 预防** * ** 改进部署验证:** 我们正在加强发布验证程序,以更好地确定配置变化。 * ** 构成部分脱钩**: 我们正在评估对各部分部署顺序的改进,以降低将意外变化纳入释放的风险。 * ** 逐步推出战略**: 我们正在审查受影响部分的推出过程,使其与用于其他关键部分的推出控制相一致。 *** 检测** * 更好地提醒**: 我们正在加强监测工作,以便更快、更可靠地发现故障率的异常上升。 * ** 军事** * ** 安全配置部署:** 我们正在改进如何部署生产配置的改变,以便它们能够被禁用或更快地回滚,而不需要更广泛的软件发布。 * ** 较快的人工回收工具**: 我们正在改进我们的恢复工具,以缩短查明和人工恢复受影响事件所需的时间。 我们承认这一事件造成的干扰,并对受影响的客户造成的影响表示歉意。 我们完成了立即采取的纠正行动,上述较长期的改进工作已在进行中,以减少今后类似事件的可能性和影响.

自动翻译自官方事件更新。

1. 2026年7月10日 UTC 17:18investigating

   我们正在调查一个影响Aura Console的问题,一些顾客可能无法看到他们的情况。 这个问题由Aura依赖的第三方服务失败所引起. 受影响的情况继续正常运行,数据库的连通性没有受到影响。 我们的小组正在积极调查这个问题.

2. 2026年7月10日 UTC 17:23investigating

   我们正在继续调查这一问题.

3. 2026年7月10日 UTC 17:51monitoring

   奥拉依赖的第三方服务恢复了正常运行,而Neo4j Aura系统也恢复了. 我们的团队正在积极监测这个问题,以证实Aura Console正在按照预期进行.

4. 2026年7月10日 UTC 19:23resolved

   经确认服务已开始运作,预计不会再中断.

5. 2026年7月27日 UTC 04:28postmortem

   # 发生的一切 # # What happened # Aura Console等Aura组件于协调世界时2026-07-10起于16:14相继中断,导致故障和坠机. 因此,一部分客户面临其案例的能见度问题。 它是由与Aura合并的外部第三方服务中断造成的. 关键是,数据库的连通性仍然不受限制,受影响的事件继续其正常运行。 为解决这一问题恢复了暗地服务 □ 服务是如何受到影响的 多个Aura组件,包括Aura Console,经历了中断. 用户在数据库相关网页和业务中遇到HTTP 500出错,尽管组织和项目仍然可以访问. 直接连接到特定数据库的情况完全没有受到影响 控制平面变得无法使用,这意味着用户无法通过API或Aura控制台创建,删除,调整大小,或调整实例设置. 然而,现有的事例仍在运作。 这个问题是由OutingDarkly的停电引起的,我们的服务在启动期间并没有优雅地处理这种依赖失败. 所有受影响的系统在协调世界时2026-07-1017:07恢复正常运作 ∮我们现在在做什么∮ Neo4j工程队迅速诊断出根源并恢复服役. 在评估这一事件时,我们确定了加快未来解决和减少再起风险的关键领域: * 分析关键事件衡量标准,侧重于警报至反应时间,以确定加快反应效率的机会 * 进行全面的回顾,强调成功结果,包括通过透明记录进行迅速的根由分析,通过事件管理工具进行无缝调整,以及使数据平面连接完好无损的多部分具有弹性和优雅的退化 * 积极开发更优雅的功能旗倒置默认,在供应商倒闭期间保护核心业务 * 通过整合先进的规划、混沌工程做法和生产层面的断层注射测试,加强建筑复原能力,以先发制人地发现并减缓潜在的故障路径 * 解决了操作者特征标记缓存的逻辑限制,强调操作者必须在当地储存被评价的旗帜,以便在外部依赖性失败时保持业务连续性.

自动翻译自官方事件更新。

1. 2026年6月30日 UTC 14:45identified

   运行 CREATE VECTOR INDEX 失败出错 51N31 错误: 系统配置或操作例外 - 不支持 。 在 V2026 02 中不支持使用提供的设置创建向量索引 。 运行所需版本为V2026 06. 请升级 DBMS.. 这只影响到新的指数,现有的VECTOR INDEX不受影响. 2026-06-30 09:00之前创建的任何向量指数继续正常运行.

2. 2026年6月30日 UTC 15:41identified

   我们现在正开始部署一个解决这一问题的办法,并将很快提供最新进展.

3. 2026年6月30日 UTC 16:05monitoring

   修复工作正在展开,进展顺利。 我们将介绍最新进展.

4. 2026年6月30日 UTC 17:45resolved

   已向所有受影响的事例充分运用了这一方法。 这一事件现在已经得到解决.

5. 2026年7月20日 UTC 08:40postmortem

   # 发生的一切 # # What happened # 在2026-06-30 UTC08:00部署2026.06版本后,发现一个问题,在升级的Aura实例上运行"CREATE VECTOR INDEQ"引发了系统例外. 索引生成的这种失败发生是因为基础存储和内核需要额外的更新来支持操作 这一问题只影响到新的指数的制定;现有的矢量指数没有受到影响。 2026-06-30日09:00前创建的任何矢量指数都未受影响,继续正常工作. □ 服务是如何受到影响的 2026.06版本推出后,CREATE VECTOR INDEX语句的执行失败,影响了依赖新增向量索引的应用程序. 受影响的客户端收到错误 : 创建带有所提供设置的向量索引在 V2026\ 02 中不支持 。 运行所需的版本为V2026\ 06. 请升级 DBMS . 已存在的索引\(在此事件之前创建)和其他查询仍然完全未受影响并充分运作. ∮我们现在在做什么∮ Neo4j团队在Cypher计划中将根源确定为bug并用代码固定解决了这个问题. 已向所有受影响的奥拉事件应用了这一修复,以完全解决错误 为了防止今后发生这种情况,我们正在加强我们的监测和警报系统,以便在推出之前尽早发现类似问题,特别是在中转环境中。 同时,我们正在完善部署程序,以尽量减少客户的影响和恢复时间 此外,我们正在研究针对矢量指数生成等关键操作实施自动化升级后验证测试的备选方案

自动翻译自官方事件更新。

1. 2026年6月23日 UTC 11:25identified

   奥拉控制台正在经历一些间歇性错误:"我们的系统正在遇到问题. 如果问题继续存在,请稍后再次尝试或联系支持。" 这可能需要您重新装入或等待更长的时间在控制台进行导航 业务和Aura API没有受到影响 我们正在努力解决

2. 2026年6月23日 UTC 13:03identified

   我们正在继续调查解决这个问题的办法

3. 2026年6月23日 UTC 13:39identified

   我们正在继续努力解决这个问题。

4. 2026年6月23日 UTC 15:43monitoring

   我们正在部署一个变化。 我们将监测和更新.

5. 2026年6月23日 UTC 19:27monitoring

   继续监测已部署的变化。 下一次更新预计世界协调时上午10时6/24/2026.

6. 2026年6月24日 UTC 09:14monitoring

   我们检查并确认,这一问题现已得到全面解决.

7. 2026年6月24日 UTC 09:14resolved

   这一事件已经得到解决.

8. 2026年7月10日 UTC 14:50postmortem

   # 发生的一切 # # What happened # 2026年1月22日 UTC中午12点左右,用户在Aura控制台内出现间歇性出错横幅显示,"我们遇到了问题. 再试一次...",这与控制台API端点的500个错误同时发生. 这些中断是短暂的,由TLS握手过程中的API内部出局时间所造成,一般在10秒左右或更新后解决 □ 服务是如何受到影响的 Aura Console和Aura API的性能退化了,表现为Aura控制台UI内的间歇性出错横幅. 一项调查确定,根源在于控制台内CPU使用率高和节流. API. 造成这一问题的主要原因是多次提出大型实体清单和要求核对员费用昂贵 为了解决这一问题,向Aura控制台和Aura API成功地部署了有针对性的解决办法。 随后调整了资源配置,以增加业务头室并确保稳定性 ∮我们现在在做什么∮ 为了减少发生类似事件的可能性,采取了下列反应性和主动性措施: * 开发一个监测仪表板,根据API内部日志数据观察请求的下降情况,以便在捕获问题发生之前进行自动监测和提醒 * 为减少高资源消耗和改善API稳定,在调和方请求之间错开时间 * 提高基础设施对资源的认识,以改进业绩 * 引入了基于服务级别查询的新过滤器,以优化调和器每次调用时的CPU管理费用 * 取消冗余请求中间软件处理,以优化API呼叫

自动翻译自官方事件更新。

1. 2026年5月26日 UTC 18:23investigating

   Aura Console is currently not accessible. Our team is investigating the issue. Aura instances are running normally and are not impacted. They remain accessible via https://browser.neo4j.io/ and https://bloom.neo4j.io/ Console-related administration and configuration procedures may be unavailable. We will provide updates as soon as more information is available.

2. 2026年5月26日 UTC 19:19monitoring

   The Aura Console issue has now been resolved. The root cause was a failure while fetching public certificates from Auth0. We are reaching out to the Auth0 team to gather more detailed information about the incident.

3. 2026年5月26日 UTC 23:06resolved

   This incident has been resolved.

4. 2026年6月9日 UTC 16:50postmortem

   **What Happened** During the incident window, users attempting to log in to the Aura Console were unable to do so. Auth0, the authentication provider for Aura Console, experienced an issue that prevented new authentication requests from completing. Existing sessions with valid cached tokens were largely unaffected. Aura database instances were running normally throughout and were not impacted, and access via the Aura API to database instances was also unaffected. **How the service was affected** Authentication requests from the Aura Console to Auth0 began failing, preventing new logins and session refreshes. Affected users received 503 errors when accessing the Aura Console. Once Auth0 recovered, access was restored. **What are we doing now** We've made two changes as a result of this incident: * Client identification: Authentication requests now include a clearer client identifier, reducing the chance of requests being incorrectly blocked in the future. * Observability: We've improved logging and alerting for authentication failures, including better visibility into errors from external services,so we can detect and escalate issues like this faster.

1. 2026年3月6日 UTC 10:18identified

   We identified an issue with the availability of console.neo4j.io - we are investigating

2. 2026年3月6日 UTC 10:24monitoring

   We have made a code change and we believe the console is available again.

3. 2026年3月6日 UTC 10:25resolved

   We have checked and confirm that the issue is now fully addressed.

4. 2026年3月30日 UTC 07:25postmortem

   ## What Happened On March 6, at 10:04 AM UTC,  the Aura Console became inaccessible following a recent deployment. The deployment included changes related to user organizations and switching to an org memberships entity. This change caused the console to become inaccessible for a short period. ## How the service was affected A deployment to the Aura Console introduced an issue that caused an unexpected increase in backend requests related to access validation. This led to elevated CPU usage, which impacted the availability of the console and dependent services. We rolled back to a previous version to restore access. The rollback ensured the full restoration of access to the Aura Console, resolving the core issue within the incident window ## What are we doing now We are currently implementing a comprehensive strategy to bolster system resilience and prevent future recurrence. Our immediate actions include integrating stricter and more robust safeguards into the deployment pipeline. Crucially, we are significantly enhancing our validation processes to proactively detect and flag any potential performance impacts _before_ code is promoted to the production environment

1. 2026年3月3日 UTC 21:35identified

   A recent update resulted in MERGE queries which referenced the same merged property on both the left and right hand side of an ON MATCH SET or ON CREATE SET clause deleting that property from the node, or setting it to an invalid value during query runtime. The node being matched against must have had at least one property uniqueness constraint present. A fix has been identified and will be applied as soon as possible. Instances marked as "Production" are not impacted.

2. 2026年3月4日 UTC 01:39identified

   The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.

3. 2026年3月4日 UTC 04:52identified

   The fix is being deployed and the status page will be updated upon completion of the full deployment

4. 2026年3月4日 UTC 14:07monitoring

   The fix has now been deployed to those instances impacted and we are monitoring the situation.

5. 2026年3月4日 UTC 15:19resolved

   The fix has been fully deployed to all impacted instances. This incident is now resolved.

6. 2026年4月8日 UTC 06:39postmortem

   ## What Happened An issue was introduced in the Neo4j 2026.02 release where MERGE queries that referenced the same property on both the left and right sides of an `ON MATCH SET` or `ON CREATE SET` clause could potentially delete that property from the node or set it to an invalid value during query execution. This behaviour was observed specifically when the node being matched had at least one property uniqueness constraint. ## How the service was affected A change in the Neo4j 2026.02 release introduced a potential risk of writes failing or invalid data being returned for queries using MERGE together with `ON MATCH`. This issue affected instances across Aura tiers and required immediate investigation by Neo4j Engineering. The team identified the root cause and deployed a fix in version 2026.02.1. ## What are we doing now The following proactive measures have been implemented to reduce the likelihood of similar incidents: * We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions. * We are investigating additional safeguards to improve our ability to control MergeInto/MergeUnique behaviour more flexibly, as well as potential rollback capabilities to support recovery in future incidents

1. 2026年3月2日 UTC 19:55identified

   We are aware of issues in the Middle East regions via our cloud partner AWS, affecting AWS me-central-1 (United Arab Emirates) and AWS me-south-1 (Bahrain). The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We are actively working to limit the impact on the Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels. Our team is available to advise and assist as needed.

2. 2026年3月3日 UTC 15:26identified

   We continue to monitor the situation in the affected AWS Middle East regions. The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as soon as more information becomes available.

3. 2026年3月6日 UTC 14:29identified

   We continue to monitor the situation in the affected AWS Middle East regions. The latest information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as more information becomes available. Please review the AWS recommendation on the website above.

4. 2026年3月6日 UTC 16:06resolved

   While AWS continues working on this situation, we are closing this incident and invite our customers to monitor the AWS Status on our main Neo4j Status Page under AWS (Amazon Web Services). The latest information from AWS can be found at: https://health.aws.amazon.com/health/status

5. 2026年3月29日 UTC 15:16postmortem

   ## What Happened On March 1, at 12:51 PM UTC, AWS services in the ME-CENTRAL-1 & ME-SOUTH-1 Region were impacted. Connectivity and power issues affected APIs and AWS core services essential to run Neo4j Aura prompting AWS to initiate an investigation ## How the service was affected Operations \(clone, backup, resuming/pausing, resizing\) that require additional resources like EC2 Instances, EBS Volumes, and other resources were impaired in the ME-CENTRAL-1 and ME-SOUTH-1 Region. Other AWS Services also experienced error rates and latencies for some workflows. Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure. A detailed summary of the AWS regional incident can be found here:[ https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status) ## What are we doing now We are actively working to limit the impact on the Neo4j Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels Please visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)