Download as PDF, PPTX
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fawsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
More from yoku0825
MySQLのバックアップ運用について色々
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.1/1のフル + 1/2の増分+ 1/3の増分 +1/4の増分9/58
- 11.あるいは1/1のフル + 1/3の差分+ 1/4の増分10/58
- 12.ステップ的なものサイズ 使いどころ コマンド例フルバックアップでかい 必ず必要 tar, rsync,mysqldump,XtraBackup差分バックアップ ⼩さい フルバックアップの間隔が短ければ要らないmysqldump(スキーマに制約)XtraBackup増分バックアップ 更新量に依存 ほぼ間違いなく必要 cp, rsync,mysqlbinlog11/58
- 13.
- 14.フルバックアップの選択肢コマンド エンジン アプリ影響⽅式 サイズtar, rsync MyISAM ×停⽌またはロック物理 ⼤きめtar, rsync InnoDB ×mysqld停⽌物理 ⼤きめLVMスナップショットMyISAMInnoDB△性能劣化がひどい物理 ⼤きめmysqldump MyISAM ×ロック論理 ⼩さめmysqldump InnoDB ○ 論理 ⼩さめXtraBackup MyISAM ×ロック物理 ⼤きめXtraBackup InnoDB ○ 物理+論理 ⼤きめ13/58
- 15.フルリストアのしやすさコマンド エンジン リストアのしやすさ時間tar, rsync MyISAMInnoDB簡単 短いmysqldump MyISAMInnoDB簡単 超⻑いXtraBackup MyISAMInnoDB慣れるまで⾯倒 やや短い14/58
- 16.増分バックアップバックアップscp, rsynなどでコピー-MySQL 5.6からは–raw–stop-neverでリアルタイムバックアップもできる-リストアmysqlbinlogでデコード-15/58
- 17.
- 18.
- 19.
- 20.ここまでのまとめXtraBackupの特徴ホットな物理バックアップ、しかもマルチスレッド-慣れるまで難しいものの、慣れれば夢のソリューション-ただしMyISAMが混じるとロックが必要-最新版はMySQL 5.1 InnoDBPlugin以降のサポート-MySQL Enterprise Backup(商⽤版MySQLのユーティリティー)がもっと便利なことできる-19/58
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.リストアのケースを整理データのロールバック(ロールフォワードリカバリー)ロールバック時点から1世代前のフルバックアップからのリストア + ロールバック時点までのbinlog適⽤-⾯倒+ 時間かかる上に⼤概急ぐ-原因はだいたい「やらかした」もしくはおもむろに「過去のスナップショット⾒たい」とか、事前に予測のつかない理由-最低限の準備だけしてあとはその時考える39/58
- 41.
- 42.
- 43.クラッシュしたらデータを全て消してバックアップサーバーからコピーした⽅がいい場合クラッシュアンセーフなストレージエンジンMyISAM, Mroonga, その他InnoDBでもinnodb̲flush̲log̲at̲trx̲commit!= 1なマスターskip-innodb-doublewrite羃等でないSQLを使っているスレーブsync̲master̲info, sync̲relay̲log̲infoを両⽅1にできないものとして考えてるUPDATE .. SET age= age + 1 は2回実⾏すると結果がズレるUPDATE .. SET age= 32 ならまだマシbinlog̲format= ROWならエラってくれるはず-42/58
- 44.
- 45.クラッシュするんだからなるべくスレーブで重複実⾏されても痛みが少ないSQLを選ぶトランザクションを使ってSELECTして値を得てからその値でUPDATE-MySQL 5.6以降ならrelay̲log̲recovery= 1&&relay̲log̲info̲repository= TABLEでクラッシュセーフスレーブに(クラッシュしてもレプリケーションが正しく再開される)-44/58
- 46.
- 47.クラッシュしたあとはマスターのsync̲binlog != 1だと、スレーブのmaster̲log̲positionが先に進んでしまうとかどっちを⽣かす︖-log̲slave̲updatesしてればスレーブを⽣かせるんだけどさ。。GTID有効ならlog̲slave̲updates必須なので、⼀意に選択できる。-⾃動昇格に任せるという⼿もある(DurabilityよりもConsistencyとAvailabilityを取る)-46/58
- 48.
- 49.モニタリングは⼤事レプリケーションに不整合は起きていないのかリストアできたとしても、間違ったデータじゃ意味がないbinlog̲format= STATEMENT &&sysdate-is-nowしてない状態でsysdateとか(実話)非決定性クエリーに関してはエラーログに吐いてくれる。binlog̲format= ROWで Error: 1032(HA̲ERR̲KEY̲NOT̲FOUND) で⽌まってくれた⽅がマシ(感じ⽅には個⼈差があります)マスターからバックアップするのが⼀番確実ではあるバックアップサーバーに直接UPDATE⽂を投げられたことがあってだな。。read-only付け忘れるとかSuper̲priv良くないpt-table-checksumが簡単だけど、テーブルサイズが⼤きくなってくるとなかなかつらいものもある。。-48/58
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.直観的なヒント⽌めて物理バックアップ => mysqldump=>XtraBackup => 混合、と推移していくものかなと思う。次のステップに進むべき時にはたぶん⾃然とわかる⽌めて物理バックアップで⾜りている時期にはXtraBackupのドキュメント読んでもきっと⾯⽩くもなんともないmysqldumpでリストアが無理だろうってなった時にはXtraBackupの機能はきっとわかる順当にやってきてれば、XtraBackupだけでつらくなってきた時に他の選択肢をきっと思いつく-56/58
- 58.
- 59.