-
surumegohan
- 1868
- 7
- 0
- 0
-
- いいね！0
しょー（show）
@surumegohan
レプリケーションで、スタンバイサイトをバックアップ取得先として利用することも可能。本番環境に影響を与えずにバックアップ取得可能 #mysql_jp
2017-07-03 14:15:10
しょー（show）
@surumegohan
レプリケーションの欠点： ・復旧ポイントは障害発生直前の状態のみ ・人的ミスに対する対策にはならない #mysql_jp
2017-07-03 14:16:51
しょー（show）
@surumegohan
RTO：（Recoverry Tiime Objective）目標復旧時間 障害発生時に「いつまで復旧するか」という目標時間 リストア＋リカバリの時間の総和となる #mysql_jp
2017-07-03 14:18:36
kk2170@悪影響を及ぼす
@kk2170
RTO(Recovery Time Objective)とかRPO(Recovery Point Objective)って初耳だ。「できるだけ戻せたほうが良い」「できるだけ早く」とかよりはちゃんと考えたほうが良さそう。 #mysql_jp
2017-07-03 14:18:51
しょー（show）
@surumegohan
RPO（Recoverry Point Objective)：目標復旧辞典 障害発生時に「どの時点までのデータを復旧する必要があるのか」という目標辞時点 #mysql_jp
2017-07-03 14:19:31
kk2170@悪影響を及ぼす
@kk2170
バックアップは最低でも2世代は必要。バックアップの処理が完了するまでは、前の世代を捨てられない。ストレージとの相談 #mysql_jp
2017-07-03 14:21:43
しょー（show）
@surumegohan
バックアップ運用設計時の主な考慮事項 ・バックアップの保存期間、保存場所 ・バックアップを何世代保管するか（最低2世代！） ・どこに保管するか ・バックアップの取得頻度や手法はシステム要件にあわせる #mysql_jp
2017-07-03 14:22:13
しょー（show）
@surumegohan
バックアップ対象 ・データディレクトリ、データ全体 ・ログファイル（バイナリログ） ・設定ファイル(my.cnf) #mysql_jp
2017-07-03 14:24:32
kk2170@悪影響を及ぼす
@kk2170
バックアップ対象にはmy.cnfファイルも入れる(その時の状態に戻せるように) my.cnfがいろんなところにあると辛いな… #mysql_jp
2017-07-03 14:24:34
しょー（show）
@surumegohan
データディレクトリとバイナリログは別のディスクに出力することを推奨 → IO分散、ストレージ障害時の考慮 #mysql_jp
2017-07-03 14:28:30
しょー（show）
@surumegohan
バイナリログは mysqlbinlogコマンドでテキスト化が可能 5.7からbinlog_format=ROWがデフォルト #mysql_jp
2017-07-03 14:30:16
kk2170@悪影響を及ぼす
@kk2170
binlog_row_image=minimalを設定するときはマスターとスレーブのテーブル定義が同一でないとだめ。って書いてあるけど、マスターとスレーブでテーブル定義ずらして運用するって一体どういう状況なの？ #mysql_jp
2017-07-03 14:33:03
ブリンガー
@bringer1092
バイナリ形式は5.7でROWがになっているが （ROWが推奨になっているものも多い） サイズを考えるとbinlog-row-image = MINIMALにするべきだが レプリケーションで異なるエンジンを使っているイレギュラーでは問題があるかも #mysql_jp
2017-07-03 14:40:11
しょー（show）
@surumegohan
一般的なデータベースの特性をもっているストレージエンジンはInnoDB 特別な要件がないならInnoDBで良いです。 MyISAMでしかできないことはなくす方向で開発が進んでいる #mysql_jp
2017-07-03 14:40:42