AWS MySQL Aurora 主要版本(2 -> 3)升级预检查:"Obsolete procedure"
AWS MySQL Aurora major version (2 -> 3) upgrade pre-checks: "Obsolete procedure"
我们相信我们已经注意到 Aurora 2 到 3 / Mysql 5.7 到 8.0 的 AWS 升级预检查中的一些奇怪行为。
我们认为它与特定于 AWS 的规则有关"There must be no queries and stored program definitions from MySQL 8.0.12 or lower that use ASC or DESC qualifiers for GROUP BY clauses,",但我们并未违反此规则。
我们的发现:(SP1)
DELIMITER $$
CREATE PROCEDURE sp_1 ()
BEGIN
SELECT st.name as hdervascferef, max(st.status)
FROM SetupTableName st
GROUP BY st.name;
END$$
DELIMITER ;
产生预检错误:
{
"level": "Error",
"dbObject": "trax.sp_1",
"description": "Obsolete procedure - trax.sp_1. Contains depreciated keywords."
},
但是:(SP2)
DELIMITER $$
CREATE PROCEDURE sp_2 ()
BEGIN
SELECT st.name as hdervasferef, max(st.status)
FROM SetupTableName st
GROUP BY st.name;
END$$
DELIMITER ;
不会产生错误。
这里唯一的区别是来自 SP1 的别名 hdervascferef
是一个包含子字符串 asc
的任意字符串,而来自 SP2 的别名 hdervasferef
别名具有 'c' 已删除,因此不包含子字符串 asc
,因此没有错误。
我们在许多存储过程中 运行 因为我们有许多表的列名为 hasChilds
,它有 asc
子字符串,因此阻止了这些 SP 传递预检查。我们发现从 SP 中删除字母 asc
的实例会导致预检查通过,但这对我们来说不是一个可行的选择,因为在我们的存储过程中使用 hasChilds
列是至关重要的他们的功能。
复制步骤:
- 将这两个 SP 添加到 engine = 5 的 AWS Aurora 实例中。7.mysql_aurora.2.07.2
- 按照 AWS RDS MySql Testing an Upgrade
中的说明进行操作
- 验证 SP1 而非 SP2 的预检失败
如果能提供任何帮助/指导,我们将不胜感激!
I've already asked this question on AWS re:Post to no avail
tl;博士
我认为我们被标记为“必须没有来自 MySQL 8.0.12 或更低版本的查询和存储的程序定义使用 GROUP BY 子句的 ASC 或 DESC 限定符,”由于我们的查询有一个 group by
和其中的子字符串 'asc',尽管实际上并没有违反规则,这阻止了我们升级我们的 Aurora 实例,因为我们没有通过预检查。
我们采用的解决方法是将所有标记的存储过程转换为使用准备好的语句来分解“asc”和“desc”的出现。使用上面的例子sp_1,转换后的SP变成
DELIMITER $$
CREATE PROCEDURE sp_1 ()
BEGIN
DECLARE selectStr varchar(4095);
SET selectStr = CONCAT('SELECT st.name as hderva', 'scferef, max(st.status)
FROM SetupTableName st
GROUP BY st.name;');
SET @sqlQuery = insertStr;
PREPARE execStr FROM @sqlQuery;
EXECUTE execStr;
END$$
DELIMITER ;
我们相信我们已经注意到 Aurora 2 到 3 / Mysql 5.7 到 8.0 的 AWS 升级预检查中的一些奇怪行为。
我们认为它与特定于 AWS 的规则有关"There must be no queries and stored program definitions from MySQL 8.0.12 or lower that use ASC or DESC qualifiers for GROUP BY clauses,",但我们并未违反此规则。
我们的发现:(SP1)
DELIMITER $$
CREATE PROCEDURE sp_1 ()
BEGIN
SELECT st.name as hdervascferef, max(st.status)
FROM SetupTableName st
GROUP BY st.name;
END$$
DELIMITER ;
产生预检错误:
{
"level": "Error",
"dbObject": "trax.sp_1",
"description": "Obsolete procedure - trax.sp_1. Contains depreciated keywords."
},
但是:(SP2)
DELIMITER $$
CREATE PROCEDURE sp_2 ()
BEGIN
SELECT st.name as hdervasferef, max(st.status)
FROM SetupTableName st
GROUP BY st.name;
END$$
DELIMITER ;
不会产生错误。
这里唯一的区别是来自 SP1 的别名 hdervascferef
是一个包含子字符串 asc
的任意字符串,而来自 SP2 的别名 hdervasferef
别名具有 'c' 已删除,因此不包含子字符串 asc
,因此没有错误。
我们在许多存储过程中 运行 因为我们有许多表的列名为 hasChilds
,它有 asc
子字符串,因此阻止了这些 SP 传递预检查。我们发现从 SP 中删除字母 asc
的实例会导致预检查通过,但这对我们来说不是一个可行的选择,因为在我们的存储过程中使用 hasChilds
列是至关重要的他们的功能。
复制步骤:
- 将这两个 SP 添加到 engine = 5 的 AWS Aurora 实例中。7.mysql_aurora.2.07.2
- 按照 AWS RDS MySql Testing an Upgrade 中的说明进行操作
- 验证 SP1 而非 SP2 的预检失败
如果能提供任何帮助/指导,我们将不胜感激!
I've already asked this question on AWS re:Post to no avail
tl;博士
我认为我们被标记为“必须没有来自 MySQL 8.0.12 或更低版本的查询和存储的程序定义使用 GROUP BY 子句的 ASC 或 DESC 限定符,”由于我们的查询有一个 group by
和其中的子字符串 'asc',尽管实际上并没有违反规则,这阻止了我们升级我们的 Aurora 实例,因为我们没有通过预检查。
我们采用的解决方法是将所有标记的存储过程转换为使用准备好的语句来分解“asc”和“desc”的出现。使用上面的例子sp_1,转换后的SP变成
DELIMITER $$
CREATE PROCEDURE sp_1 ()
BEGIN
DECLARE selectStr varchar(4095);
SET selectStr = CONCAT('SELECT st.name as hderva', 'scferef, max(st.status)
FROM SetupTableName st
GROUP BY st.name;');
SET @sqlQuery = insertStr;
PREPARE execStr FROM @sqlQuery;
EXECUTE execStr;
END$$
DELIMITER ;