仕事柄、大規模なデータ移行を何度か経験してきました。 データ移行、特にDBのマイグレーションでもなく、 システム移行のときのようなデータ構造の変更を伴う際には気をつけることがたくさんあります。 クラウドではだいぶ楽になりますが、 特にオンプレミスで検討せざるを得ない皆さんに気をつけないといけない点を共有します。 スケジューリング編 最初から検討し始めよう 開発プロジェクトにおいてシステム移行だけで4割の工数がかかると言われています。 しかし、新規システム部分の開発で頭が一杯になっていると、重要度の割に移行部分が後回しにされがちです。 移行用プログラム、移行用サーバ手配はもちろん、新規、既存システムへの影響も検討しないといけません。 できればプロジェクト開始時から人をアサインして計画を立てていきましょう。 移行自体が一つの開発プロジェクト相当です。頑張りましょう。 後半になって移行計画を立て
こんにちは、グローバル向けAWS版kintoneのバックエンドエンジニアをしている@ueokandeです。 8月になって暑い日々が続きますね。そして8月と言えば、Amazon Aurora MySQL-Compatible Edition version 1 with MySQL 5.6 compatibility(以下Aurora MySQL 5.6)のサポート終了までおよそ半年となりました。 グローバル向けAWS版kintoneでは、Aurora MySQL 5.6を採用しているバックエンドサービスがいくつかあり、チームで移行作業に取り組んできました。この移行作業は単なるアップグレードだけではなく、ダウンタイムなしでデータベースを移行するチャレンジにも取り組みました。この記事ではAmazon Auroraの移行作業の全貌と、移行戦略を紹介します。 Aurora MySQL 5.6のサポ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く