kazukiyunoue-techスマートフォン用の表示で見るkazukiyunoue-techこの広告は、90日以上更新していないブログに表示しています。MySQLAWSのRDSに、ついにリードレプリカをマスターに昇格する機能が追加されました。以下3つのケースが同記事にて紹介されています。DDLオペレーションの実行テーブルのシャーディング障害回復機能を実装する"障害回復機能を実装する"ケースは、マスターで障害が発生した際に、リードレプリカをマスターに切り替えることで復旧させる方法です。非同期なので書き込みにおけるパフォーマンス劣化が防げたり、ホットスタンバイとして寝かしておくのではなくリードレプリカとして読み込み用として利用しておけたりする事でしょうか。障害時にデータの整合性が失われる可能性があるので、注意が必要です。同時多発的にマスター用途のインスタンスを作成するってところですかね。肝心の"DDLオペレーションの実行"です。稼働に影響を及ぼす可能性があるためです。レコード数の多い大きなテーブルでは顕著に現れます。サイズ、マシンリソースによってはひとつの変更に数十分、数時間かかる可能性もあるでしょう。更新を一時的に止め、リードレプリカをマスターに昇格させ、アプリケーションの向き先を昇格したマスターへ切り替える、そんなことが可能なのです。数時間もかかる作業を行うことができるのです。新しいパラメータセットを作ります。リードレプリカに対して変更処理を行うため、デフォルトのパラメータで設定されている書き込み制限が外れたセットが必要なためです。適当な名前を付けて作成しておきます。Parametersから必要な値の変更をします。項目はread_onlyです。元々は自動でリードレプリカの場合は読み込み専用になるようになっています。これを0にしておきます。Actionsからリードレプリカを作成します。作成できたら、リードレプリカを選択した上でActionsからModifyを選択し、パラメータの設定セットを先ほど作った書き込みが可能なDDLオペレーション用のものに変えます。リードレプリカに対してスキーマ変更を実施しましょう。サービスで利用していないのでどんな負荷がかかろうが問題ないですね。変更中も変更後も問題なく伝搬は続行しているはずです。これで準備は整いました。あとは更新を一時的に停止し、スキーマ変更済みのリードレプリカをマスターに昇格しましょう。その後アプリケーションの向き先を新マスターに切り替えるだけです。あっという間にスキーマ変更済みのDBへと切り替えることができました。向き先を変更してそのまま利用することが可能です。このタイミングで昇格した方が無難ですね。acceptin...Vagrantでchef-soloをprovisionerとしたupコマンド実行時に以下...2019-05-01UI/UXの重要性をソフトウェアの本質から読み解くUI/UXの重要性が叫ばれて久しい今日。MySQLから派生したRDBMSのひとつ。読者になるはてなブログをはじめよう!kazukiyunoueさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。