RDS for MySQL にできて Aurora にできない 2 つのこと
Posted on
- #aws
Amazon Aurora への移行検証の中で、RDS for MySQL にできて Aurora にできないことを見つけました。 MySQL との高い互換性は確認できたのですが、運用する上でハマりそうです。
レプリケーションを一時停止できない
MySQL にはレプリケーションを一時停止するために STOP SLAVE が用意されています。 RDS の場合は権限がないため mysql.rds_stop_replication というストアドプロシージャを使います。
どういうときにレプリケーションを止めたいかというと、分析のためにある時点（たとえば深夜 0 時）の全データをエクスポートしたいときです。 RDS の Restore to Point in Time (PITR) だと別インスタンスを起動するので時間がかかりますが、レプリケーションの停止だと数秒で完了します。
Aurora の場合は call mysql.rds_stop_replication を実行してもレプリケーションを停止できません。
mysql> call mysql.rds_stop_replication\G
*************************** 1. row ***************************
Message: Slave is already stopped or may not be configured. Run SHOW SLAVE STATUS\G;
1 row in set (0.01 sec)
Aurora はバイナリログによるレプリケーションではないので、明示的にレプリケーションを止める手段はないようです。自分が検証した環境では、Aurora の Restore to Point in Time は MySQL と比べて数倍速かったので、これで回避しようと思っています。
リードレプリカに書き込みできない
大規模なデータベースを運用していると ALTER TABLE や CREATE INDEX といった DDL がメンテナンス時間内に終わらない可能性があります。
そういうときはリードレプリカの read_only パラメータをオフにして、事前にリードレプリカに対して DDL を流します。そして、メンテナンス中にリードレプリカをマスターに昇格させることでメンテナンス時間を短くできます。
ですが、Aurora の場合は read_only パラメータが変更できません。
よく考えれば当たり前のことで、Aurora はマスターとリードレプリカでストレージを共有しているので（リードレプリカもマスターと同じストレージを参照している）、リードレプリカに書き込めてしまうとデータの不整合が発生してしまうのです。 RDS for MySQL の場合はストレージが独立していたのでリードレプリカに DDL を流せたのです。
これを回避するには Aurora 間でレプリケーションを設定して、メンテナンス中にクラスタを丸ごと入れ替えるしか方法がないようです（AWS の SA の方にも確認済み）。 Aurora 間のレプリケーションはバイナリログを使ったやり方のほかに、今だと AWS Database Migration Service が使えるかもしれません。
まとめ
Aurora は MySQL と高い互換性を持っているのでアプリケーションからは違いを感じませんが、運用する上ではこれまでの手法が使えなくなっているかもしれません。移行するときは運用手順まで含めてよく検証する必要がありそうです。