AWSのAuroraについての雑多なメモです。
lock
インデックスが貼られていないカラムへWhere句で条件を指定してUpdateした場合に、ロックされる様子を観察します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| # ロックテスト用のテーブルとデータを作成
create table lock_test (
id int primary key auto_increment,
name varchar(32) not null
) engine=innoDB default charset=utf8mb4;
insert into lock_test (name) values
('hoge'),
('fuga'),
('hige');
# トランザクションを開始して1行更新
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> update lock_test set name = 'foo' where name = 'hige';
Query OK, 0 rows affected, 6 warnings (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 6
# 別のターミナルで他の行を更新、ロックタイムアウトでエラーとなる。
mysql> update lock_test set name = 'hage' where name = 'hoge';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
# Innodbのステータスを確認
mysql> show engine innodb status \G;
---TRANSACTION 806905833, ACTIVE 7 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 2649897, OS thread handle 0x2b0126747700, query id 135506295 10.0.1.168 hoge_dev03 updating
update lock_test set name = 'hage' where name = 'hoge'
------- TRX HAS BEEN WAITING 7 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3465 page no 3 n bits 2 index `PRIMARY` of table `hoge`.`lock_test` trx id 806905833 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 0000301862e0; asc 0 b ;;
2: len 7; hex a900000c4c0110; asc L ;;
3: len 4; hex 686f6765; asc hoge;;
|
インデックスが貼られている行でWeher句を書いた場合は行ロックとなる。
クラスタインデックスでもセカンダリインデックスでも同様。
1
2
3
4
5
6
7
8
9
10
11
12
| # プライマリインデックスが貼られたID列で更新をかける
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update lock_test set name = 'foo' where id = 3;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 0 Warnings: 0
# 別のターミナルで他の行を更新、ロックされない。
mysql> update lock_test set name = 'hage' where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
|
kill
プロセスをKillするには下記のコマンドを実行します。
1
| CALL mysql.rds_kill_query(29048690);
|
Aurora version
Auroraのバージョンを取得するにはSelect文を実行します。
1
2
3
4
5
6
| mysql> select AURORA_VERSION();
+------------------+
| AURORA_VERSION() |
+------------------+
| 1.8.1 |
+------------------+
|
Aurora restore
Masterの復元
- snapshotをとる
- 元のDBのDB Instance IdentifierとDB Instance identifierを変更する
- 1.で作成したsnapshotからDBをRestoreする。DB Instance Identifierには元のDBの設定値を指定する。
- 作成されたクラスタのセキュリティグループを変更する
- パラメータグループを変更して、再起動
replication
別クラスターでレプリケーション
http://docs.aws.amazon.com/ja%5Fjp/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html
1. クラスターパラメータグループ の binlog_format を Mixedに設定する
2. binlog保持期間を設定する
1
2
| CALL mysql.rds_set_configuration('binlog retention hours', 144); # 6日間
CALL mysql.rds_show_configuration;
|
3. スナップショットを取る
4. スナップショットからクラスタを作成する
5. 作成されたクラスタのセキュリティグループを変更する
6. パラメータグループを変更して、再起動
7. マスター側でレプリケーションユーザーを作る
1
2
| CREATE USER 'repl_user'@'%' IDENTIFIED BY 'hogepassword';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY 'hogepassword';
|
8. スレーブ側でレプリケーションを開始する。
1
2
3
4
| CALL mysql.rds_set_external_master ('master-group.cluster-xxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com', 3306,
'repl_user', 'hogepassword', 'mysql-bin-changelog.000001', 75680, 0);
-- binlogファイルとポジションはイベントログに記載されている。
CALL mysql.rds_start_replication;
|
マスターのBinlogを確認
1
2
| show master logs;
show master status;
|
スレーブのレプリケーションを確認
エラーをスキップ
1
| CALL mysql.rds_skip_repl_error;
|