8.0.16でCHECK制約がサポートされました。
CHECK制約については、「yoku0825さんのブログ」や「MySQL Server teamのブログ」で詳しく解説されてます。
さて、「8.0.16でCHECK制約を設定したテーブルをCHECK制約に対応していない8.0.15で操作したらどうなるだろ？」という疑問が湧いたので試してみました。
CHECK制約を作るじゃろ？
mysql> CREATE TABLE check_constraint (pk SERIAL PRIMARY KEY,
c1 int, CHECK(c1>0));
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO check_constraint VALUES(1, -10);
ERROR 3819 (HY000): Check constraint 'check_constraint_chk_1' is …
Jul
20
2019
Jul
18
2019
MySQL Technology Cafe #4 に参加してきました。
State of the Dolphin - What's new in MySQL
Oracleのプリセールスのえらい人、Philipさんによる、MySQL 8の新機能のオーバビューでした。
Document Store、Build in HA / InnoDB Cluster、GISの改良、InnoDB Data
Dictionary、CTE / Window Function、etc...
Mercari さんが Oracle Open World で Oracle Cloud の MySQL Analytics
で話す予定だそうです！
私は、今年は参加できなそうですが、楽しみです（きっと日本でも話が聞けるでしょう）
MySQL Replication and HA at Facebook Facebook
の松信さんのお話！
…
Jul
13
2019
MySQLどのようにテーブルスペースを復元しますか？
これは新しい情報ではありませんが、あまり取り上げていませんので、必要な人のためにここで取り上げます。
ibdファイルを紛失すると、データが失われます。
ですから、利用可能なもののコピーがある場合、または他のデータベースから同期している場合でも、それをインポートできます。
どのように/どのようにあなたはテーブルスペースを失いますか？
これはテーブルスペースを回復する簡単な例です。
mysql> Create database demo;
mysql> use demo;
mysql> CREATE TABLE `demotable` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `dts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON
UPDATE CURRENT_TIMESTAMP, …
Jul
13
2019
だから私は最近出てきたこのような状況の後、私はこれについての投稿をしていないことに気づいた。
シナリオは次のとおりです。バックアップは真夜中に行われ、データベースごとにMySQLダンプを使用しました。
それから翌日の午前10時にデータベースがクラッシュしました。
電話をかける前に一連のイベントが発生しましたが、MyISAMテーブルとIBDファイルがテーブルスペースにないデータベースのバージョンに到達しました。
そのため、オプション1、バックアップから復元すると深夜になり、何時間ものデータを失うことになります。
オプション2、私たちは何千ものibdファイルを再インポートしてすべてを保存します。 …
Jul
08
2019
今、MySQL界隈で話題沸騰の MySQL認定資格試験を受けてみました。 現在日本語で受けられるのは、「MySQL 5.7 Database Administrator (1Z0-888)」一科目のみです。 全75問を120分で解くCBTによるテストです。いつでも受けられます。58%で合格。
https://education.oracle.com/ja/mysql-57-database-administrator/pexam_1Z0-888
…
[さらに読む]
Jun
17
2019
そのため、MySQLのグループレプリケーションはMySQL 5.7で生まれました。
人々がそれについてもっと質問し始めている間今それは少し出ています。
Jun
03
2019
そのため、max_connectionsがmy.cnfファイルで設定されている値から214に低下するという問題は、Ubuntuでしばらくの間発生しています。
例として、それは2015年に戻ってここで指摘されました
私は最近これに再び遭遇し、次のステップで解決しました。
# cp /lib/systemd/system/mysql.service
/etc/systemd/system/
# cd /etc/systemd/system/
# vi mysql.service
…
Jun
03
2019
TL;DR
- MySQL Ripple を試してそっと閉じたメモ。
-
多分 こういう状態で使うんだと思う
- マスターの部分はよしなに冗長化されていると思いねえ
- （おそらく準同期レプリケーションで）マスターに直接スレーブをぶら下げると死んじゃうようなケース
- あと、このMySQL Ripple自体もたぶん多段構成するんだろうな、とデフォルトのパラメーター（主に
-ripple-master-port）を見て思う
- CentOS …
May
21
2019
TL;DR
- MySQL 8.0同士でレプリケーションを組んでいると、スレーブから以下のような
MY-010956とMY-010957がぼこぼこエラーログに吐かれることがある
2019-05-20T14:25:17.121864+09:00 5 [Warning] [MY-010956] [Server] Invalid replication timestamps: original commit timestamp is more recent than the immediate commit timestamp. This may be an issue if delayed replication is active. Make sure that servers have their clocks set to the correct time. No further message will be emitted until after timestamps become valid again.
2019-05-20T14:25:17.177804+09:00 5 [Warning] [MY-010957] [Server] The replication timestamps have returned to normal values.
- 実害はほぼないはずだけど、エラーログの肥大化に注意
- もうちょっと出力を穏やかにできないかね？ ってFeature Requestを出した …
May
19
2019
免責事項
この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。
…
[さらに読む]