19106¶
2024-08-02 Incoming¶
CloudSQLを5.7から8.0系へアップグレードしました。 しかし、プリペアドステートメントを用いたクエリの挙動が異なり、問題が発生しております。 以下について回答をお願いいたします。
一旦、mysql5.7もしくは、おそらく影響が発生していないであろうmysql8.0系へバージョンダウンを検討しています。インプレースでのバージョンダウンはできない認識ですがよろしいでしょうか。 この場合、インスタンスを新規に作成する必要があると思いますが、元のグローバルIPを引き継ぐ方法はありますでしょうか？
可能であればデータを引き継ぎたく思っています。mysql8.0系内でのバージョンダウンによる引き継ぎする方法は何かありますでしょうか？
CloudSQL MySQL8.0.31で、「パーティションを作成したテーブルで、DATE型のカラムに対して、プリペアドステートメントを使用してwhere inで検索すると正常に動作しない」ようです。 こちらはMySQLの仕様なのかバグなのか、例えばGoogle社へ問い合わせなど可能でしょうか。
例えば以下SQLを実行し、テーブルを作成、SELECTクエリを実行すると、データが取れません。
パーティションがついたテーブルを作成
use TEST;
DROP TABLE IF EXISTS `testtest`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `testtest` (
`id` int NOT NULL,
`name` varchar(45) DEFAULT NULL,
`birthdate` date DEFAULT NULL,
`season_str` varchar(10) NOT NULL,
`season_int` int NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
/*!50100 PARTITION BY LIST (`id`)
(PARTITION ptest1 VALUES IN (1) ENGINE = InnoDB,
PARTITION ptest2 VALUES IN (2) ENGINE = InnoDB) */;
/*!40101 SET character_set_client = @saved_cs_client */;
-- データ挿入
use TEST;
INSERT IGNORE INTO `testtest` VALUES (1,'fujioka','1991-06-07','2023',2023),(2,'sato','1989-11-09','2024',2024);
-- 全件取得OK
SELECT * FROM TEST.testtest;
-- パーティションがある状態でプリペアドステートメントを利用したDATE型カラムを含むIN区の利用で取得NG
-- PREPARE実施の段階でwarningメッセージが出る
PREPARE stmtaaaaaaaa1 FROM "SELECT * FROM TEST.testtest where birthdate in (?, ?)";
SET @a = '1991-06-07';
SET @b = '1989-11-09';
EXECUTE stmtaaaaaaaa1 USING @a, @b;
-- warning内容
15:36:54 PREPARE stmtaaaaaaaa1 FROM "SELECT * FROM TEST.testtest where birthdate in (?, ?)" 0 row(s) affected, 2 warning(s): 1292 Incorrect datetime value: 'XP\xFD\xBB<\x11\x00\x00\x0D\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 P\xFD\xB' 1292 Incorrect datetime value: 'XP\xFD\xBB<\x11\x00\x00\x0D\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 P\xFD\xB' Statement prepared 0.156 se
-- DATE型以外のカラム指定の場合はパーティションが設定されていてもデータ取得可能
PREPARE stmtaaaaaaaa1 FROM "SELECT * FROM TEST.testtest where season_str in (?, ?)";
SET @a = '2023';
SET @b = '2024';
EXECUTE stmtaaaaaaaa1 USING @a, @b;
-- パーティション削除後は動く
ALTER TABLE TEST.testtest REMOVE PARTITIONING;
PREPARE stmtaaaaaaaa1 FROM "SELECT * FROM TEST.testtest where birthdate in (?, ?)";
SET @a = '1991-06-07';
SET @b = '1989-11-09';
EXECUTE stmtaaaaaaaa1 USING @a, @b;
2024-08-05 Sent¶
株式会社共同通信デジタル 松岡 様
お世話になっております、株式会社G-genサポートの高井です。 お問い合わせいただきありがとうございます。ご案内にお時間いただいており恐れ入ります。
ご質問いただいた内容について下記にご案内いたします。
一旦、mysql5.7もしくは、おそらく影響が発生していないであろうmysql8.0系へバージョンダウンを検討しています。インプレースでのバージョンダウンはできない認識ですがよろしいでしょうか。 この場合、インスタンスを新規に作成する必要があると思いますが、元のグローバルIPを引き継ぐ方法はありますでしょうか？
ご認識あっております。恐れ入りますが、パブリック IP アドレスについても引き継ぎは不可能となっております。
可能であればデータを引き継ぎたく思っています。mysql8.0系内でのバージョンダウンによる引き継ぎする方法は何かありますでしょうか？
こちらについては、現在稼動されている Cloud SQL インスタンスにあるデータをバックアップなどで取得し、新しいインスタンスを作成後に取得したデータを投入すれば問題ないかと存じます。
CloudSQL MySQL8.0.31で、「パーティションを作成したテーブルで、DATE型のカラムに対して、プリペアドステートメントを使用してwhere inで検索すると正常に動作しない」ようです。 こちらはMySQLの仕様なのかバグなのか、例えばGoogle社へ問い合わせなど可能でしょうか。
こちらについても大変恐縮ですが、当サポートでも該当する情報は持ち合わせておりません。 MySQL 自体の仕様またはバグである可能性も考えられますが、Cloud SQL for MySQL 特有の事象かを Google 連携も視野に入れつつ検証・調査いたしますので、少々お時間いただけますようお願い申し上げます。
ご不便おかけしており恐れ入りますが、引き続きよろしくお願いいたします。
2024-08-07 Sent¶
株式会社共同通信デジタル 松岡 様
お世話になっております、株式会社G-genサポートの高井です。 ご案内にお時間いただいており恐れ入ります。保留となっておりました件について下記にご案内いたします。
CloudSQL MySQL8.0.31で、「パーティションを作成したテーブルで、DATE型のカラムに対して、プリペアドステートメントを使用してwhere inで検索すると正常に動作しない」ようです。 こちらはMySQLの仕様なのかバグなのか、例えばGoogle社へ問い合わせなど可能でしょうか。
当サポートにて検証・調査いたしましたところ「特定の MySQL バージョン(弊社では 8.0.31, 8.0.32)のみで再現し、Cloud SQL 特有の障害・バグではない」ことを確認いたしました。 そのため大変恐れ入りますが、当サポート及び Google 窓口にてご案内できる情報が無いため、継続の調査及びご案内ができかねる状況でございます。 また、どちらも英語のページではございますが、MySQL 公式リリースノート[1]やフォーラム[2]がございあすので、ご活用いただければと存じます。
[1] MySQL 8.0 Release Notes (MySQL 公式ドキュメント) https://dev.mysql.com/doc/relnotes/mysql/8.0/en/
[2] MySQL Forums (MySQL 公式フォーラム) https://forums.mysql.com
詳細なご案内ができず大変恐縮ではございますが、ご理解いただけますと幸いです。 ご質問いただいております内容への回答は以上となりますが、認識の相違ある場合や不明点などありましたらお知らせくださいませ。 引き続きどうぞよろしくお願いいたします。
2024-08-07 Incoming¶
株式会社G-gen 高井 様
お世話になっております。 共同通信デジタル 松岡です。
ご回答ありがとうございます。 MySQLの仕様なのかバグなのか、の件ですが、念の為確認させて頂きたく存じます
MySQL由来の問題については、CloudSQLの保証対象ではない認識でよろしいでしょうか。
Google社からバグレポートなどを報告していただくこともできないでしょうか。
以上、よろしくお願いいたします。
2024-08-08 Sent¶
株式会社共同通信デジタル 松岡 様
お世話になっております、株式会社G-genサポートの高井です。 ご確認ありがとうございます。追加でご質問いただいた内容について下記にご案内いたします。
MySQL由来の問題については、CloudSQLの保証対象ではない認識でよろしいでしょうか。
Google社からバグレポートなどを報告していただくこともできないでしょうか。
恐れ入りますが、当事象は Cloud SQL ではなく MySQL 自体の仕様もしくはバグに起因する事象のため、Google によるサポート・保証の対象外となりますことをご理解いただけますと幸いです。 また、同様に Google による MySQL 本体へのバグレポート送付につきましても、恐れ入りますが上記理由により対応ができかねる状況でございます。
なお、本件の事象につきましては Cloud SQL 側にて MySQL マイナー バージョンのアップグレードで解決する可能性がございます。 こちらの検証・調査並びに手順のご案内をさせていただくことは可能となっておりますので、ご希望の場合はお申し付けくださいませ。
ご不便おかけしており恐れ入りますが、引き続きよろしくお願いいたします。