Aurora

Table of Contents

Aurora

lock

インデックスが貼られていないカラムへWhere句で条件を指定してUpdateした場合に、ロックされる様子を観察する。

# ロックテスト用のテーブルとデータを作成
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句を書いた場合は行ロックとなる。 クラスタインデックスでもセカンダリインデックスでも同様。

# プライマリインデックスが貼られた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

CALL mysql.rds_kill_query(29048690) ;

aurora version

mysql> select AURORA_VERSION();
+------------------+
| AURORA_VERSION() |
+------------------+
| 1.8.1            |
+------------------+

aurora restore

Masterの復元

  1. snapshotをとる
  2. 元のDBのDB Instance IdentifierとDB Instance identifierを変更する
  3. 1.で作成したsnapshotからDBをRestoreする。DB Instance Identifierには元のDBの設定値を指定する。
  4. 作成されたクラスタのセキュリティグループを変更する
  5. パラメータグループを変更して、再起動

replication

Auroraで別クラスターでレプリケーションさせる方法

http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html

  1. クラスターパラメータグループ の binlog_format を Mixedに設定する
  2. binlog保持期間を設定する CALL mysql.rds_set_configuration('binlog retention hours', 144); # 6日間 CALL mysql.rds_show_configuration;
  3. スナップショットを取る
  4. スナップショットからクラスタを作成する
  5. 作成されたクラスタのセキュリティグループを変更する
  6. パラメータグループを変更して、再起動
  7. マスター側でレプリケーションユーザーを作る CREATE USER 'repl_user'@'%' IDENTIFIED BY 'hogepassword'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON . TO 'repl_user'@'%' IDENTIFIED BY 'hogepassword';
  8. スレーブ側でレプリケーションを開始する。 CALL mysql.rds_set_external_master ('master-group.cluster-cbx45t05x5yk.ap-northeast-1.rds.amazonaws.com', 3306, 'repl_user', 'hogepassword', 'mysql-bin-changelog.000001', 75680, 0); binlogファイルとポジションはイベントログに記載されている。 CALL mysql.rds_start_replication;

マスターのBinlogを確認

show master logs; show master status;

スレーブのレプリケーションを確認

show slave status;

エラーをスキップ

CALL mysql.rds_skip_repl_error;

Validate