TL;DR
REPEATABLE-READの場合、SELECT ..
FOR UPDATEやSELECT .. LOCK IN SHARE
MODEとロックなしのSELECTの結果が違うことがある。
ドキュメント探してみたけどほんのちょっとだけしか書いてないような気がする。 SELECT … LOCK IN SHARE MODE は、 これらの行のいずれかがコミットされていない別のトランザクションによって変更された場合、クエリーはそのトランザクションが終了するまで待機してから、最新の値を使用します。 …
[さらに読む]
InnoDB Clusterの設定を行い、Group
ReplicationはシングルマスターモードがDefaultなので、
Auto_Incrementの値も普段使いなれている値の1に設定し直して利用する事にしました。
Note: InnoDB Cluster = MySQL Group Replication + MySQL Router + MySQL Shell
もし、Group Replicationをシングルマスターモードで利用する予定の場合は、
実際にサーバーの初期設定時の段階で予め変更しておくと良いかと思います。
マルチマスターモードの場合は、ぶつからないように設定しておく必要があるので、
先ずは、Default設定の7で利用するのが良いでしょう。
念の為、構成がシングルマスターモードになっているか確認
Confirm is Group Replication configured as Single Master Mode.
mysql> show variables like …[さらに読む]
MySQLユーザ会会 in 長野 2017に逝ってきました！ 開催の経緯とかはとみたさんのブログ MySQLユーザ会会 in 長野 を開催しました - @tmtms のメモ 、当日のふいんき（何故か変換できない）はTogetter MySQLユーザ会会 in 長野 2017 - Togetterまとめ がまとまってます。 セッションの内容は坂井さんがMySQLとはみたいなことやると聞いていたし、かじやまさんは「MySQL …
[さらに読む]MySQL Group Replicationの監視に関しては、Performance_schemaからレプリケーションの状態を確認して、モニタリングする事が可能ですが、MySQL Enterprise Monitor3.4ではGroup ReplicationのトポロジーViewやAdvisor等で、モニタリングを簡素化して、システムの安定稼働と運用負荷を軽減してくれるようになりました。自作でモニタリングツールを作る事も可能ですが、ツールのアップデート等に工数がかかるので、出来るだけ既存のツールを利用したい場合は有用かと思います。
Group Replicationステータスモニタリング用オブジェクト
(Group Replication Status Monitoring MySQL Objects)
performance_schema.replication_group_member_stats
performance_schema.replication_group_members
performance_schema.replication_connection_status
…
この記事では、mysqlpumpコマンドの使い方を見てみようと思います。
mysqlpumpは論理バックアップを取得するツールです（実ファイルではなく、データをSQLとしてバックアップするという意味）。このツールは
MySQL5.7.8
で追加され、データベースをダンプする、もしくはダンプしたファイルを別のDBサーバに転送/インポートする目的に使用できます（インポート先はMySQLに限定されません）。
使用方法はmysqldumpと基本的に同じですが、いくつか新しい機能が含まれています。多くのオプションが変わらず使用できますが、mysqldumpとの互換性に縛られることがないよう、一から開発されています。
主な新しい機能
去年も同じころ関西DB勉強会でお話させていただきましたが、今年もまた参加させていただきます。
第５回 関西DB勉強会
2017/05/20(土)12:00 〜 19:00
@Insight Technology 大阪支店
木村からFirebird/MySQL観点のお話をさせていただきます。
お近くに住まわれていて、ご興味ありましたら、ぜひご参加ください。
懇親会もありますので、木村の馬鹿話が聞きたいひとはそちらもぜひ :) !
JUGEMテーマ：コンピュータ
See also New monitoring replication features and more! |
MySQL High Availability
original_committed_timestampはマスターで実行された時のタイムスタンプが、immediate_commit_timestampはそのサーバーで実際に実行された時のタイムスタンプがそれぞれ入る。
単位はいずれもマイクロ秒。 マスターで実行した CREATE DATABASE d1 のバイナリーログ。
$ /usr/mysql/8.0.1/bin/mysqlbinlog master/data/mysql-bin.000002
..
#170428 17:54:25 server id 1 end_log_pos 226 CRC32 0xe0efd740 GTID last_committed=0 sequence_number=1 original_committed_timestamp=1493369665593157 immediate_commit_timestamp=1493369665593157
# original_commit_timestamp=1493369665593157 (2017-04-28 17:54:25.593157 JST)
# immediate_commit_timestamp=1493369665593157 …[さらに読む]
MySQL 5.7とそれ以前で、「存在するテーブルと存在しないテーブルを一緒にDROP TABLE」しようとすると
mysql57> CREATE TABLE t1 (num int);
Query OK, 0 rows affected (0.01 sec)
mysql57> CREATE TABLE t3 (num int);
Query OK, 0 rows affected (0.01 sec)
mysql57> SHOW TABLES;
+--------------+
| Tables_in_d1 |
+--------------+
| t1 |
| t3 |
+--------------+
2 rows in set (0.00 sec)
mysql57> DROP TABLE t1, t2, t3;
ERROR 1051 (42S02): Unknown table 'd1.t2'
mysql57> SHOW TABLES;
Empty set (0.00 sec)
エラーにはなるけど消せるものは消える。 MySQL 8.0だと
mysql80> CREATE TABLE t1 (num int);
Query OK, 0 rows affected (0.01 sec)
mysql80> CREATE TABLE t3 (num int);
Query OK, 0 rows affected (0.01 sec)
mysql80> SHOW …[さらに読む]
この CREATE TABLE ステートメントは転ける。
mysql57> CREATE TABLE t1 (num INT UNSIGNED NOT NULL, dt DATETIME(3) DEFAULT CURRENT_TIMESTAMP);
ERROR 1067 (42000): Invalid default value for 'dt'
CURRENT_TIMESTAMP関数 が
DATETIME(0)型 を返すので、dtカラムの型である
DATETIME(3)型 と合わないからだというわけで、
mysql57> CREATE TABLE t1 (num INT UNSIGNED NOT NULL, dt DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3));
Query OK, 0 rows affected (0.01 sec)
mysql57> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`num` int(10) unsigned NOT NULL,
`dt` datetime(3) DEFAULT …[さらに読む]