Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

0

Share

Download to read offline

MySQL入門

Download to read offline

MySQLの社内勉強会資料1

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

MySQL入門

  1. 1. sh-ogawa 2016/9/7
  2. 2.  MySQLとは  MySQLの歴史  MySQLのメリット  MySQLのデメリット  MySQLの特徴  初心者が陥る問題
  3. 3.  オープンソースDBの中では普及率世界一  GPLライセンス 商用ライセンスもある  最近はPostgerSQLに押され気味(日本では)  LAMPって最近あまり聞かなくなったけど、 根強い人気があるため、MySQLを知っている エンジニアの数は多い  ORACLE社の持ち物
  4. 4.  1979年に、TcXという会社に務めていたMonty Wideniusによって16KB RAM搭載の4MHzコン ピュータで動くBasicで書かれたレポーティング ツールを作ったのがはじまり(Uniregというサー ビス)  1990年代にUniregにSQLインタフェースを求めら れたときに、Cで書き直されてUnixに移植  1996年5月:バージョン1のクローズドリリース  1996年10月にバージョン3.11.1正式リリースで世 に出た  1998年に多数のOSで動くようになり爆発的な普 及を果たす  日本でも割とよく使われているver5.1は2005年リ リース(サポート終了したので今から使うのは辞 めよう)
  5. 5.  2008年にSunが10億ドルで買収  が、2010年にOracleが74億でSunを買収  OracleがMySQLの面倒(verup)をあまりしな かったため、有名どころのLinuxディストリ ビューションがすべてMariaDBをデフォルトDBへ 変更  現在は割としっかりと開発されていて、最新の安 定バージョンが5.7、次期バージョンの5.8の開発 もそろそろ始まる(始まっている)はず  MySQLベースのDBで有名なもの以下がある ・MariaDB ・Amazon Aurora
  6. 6.  情報が豊富(日本語も)  事例も豊富(DeNAやFacebookもMySQLを使用)  マルチプラットフォーム  オープンソースだから、低予算化が計れる  色々なフレームワーク、MWがMySQLと連携できる ようになっている  障害には強い(勿論使い方による)  サポートは手厚い(セキュリティパッチはすぐに 出る)  バージョンアップ(パッチ当て)は容易
  7. 7.  ライセンスがGPL 以下に当てはまらないOSSを組み合わせる場合は、 おとなしくライセンスを買いましょう! http://www.mysql.com/about/legal/licensing/fos s-exception/  作りがシンプルなため、DBの入りにMySQLを選ぶ と、他DBを使うときにしんどい思いをする(実績)  弊社で使う場合は、ライセンス料を取るという面 で上役の心象は悪いです
  8. 8.  マルチスレッド型 →ケースによるけど、RAMよりもCPUの数を優先さ せるのが吉  マルチプロセスにも対応 →最近できることを知ったので、どこまでやれるの か不明!((+_+)) 情報収集&検証して使おう  テーブルの種類が豊富 →後程説明  ユーザはホスト + ユーザ名で管理される →後程説明  データベースにユーザを紐づける →後程説明  レプリケーションの歴史が長いため信頼できる →後程説明  統計情報を取るというのは気にしないで良い (チューニングするときに参照はする) →後程説明
  9. 9. MySQLのテーブルはストレージエンジンという もので、内部構造や動作を変えることができま す。
  10. 10. 以下のストレージエンジンがあります。  MyISAM  Merge  InnoDB  MEMORY  Archive  CSV  Federated  Blackhole  NDB Cluster  Falcon  PBXT  Maria
  11. 11. 以下のストレージエンジンがあります。  MyISAM  Merge  InnoDB  MEMORY  Archive  CSV  Federated  Blackhole  NDB Cluster  Falcon  PBXT  Maria 普段使うのはこの辺だ け普段使うのはこの 辺だけ 普段使うのはこの辺だけ
  12. 12. 以下の特徴があります。  ロックがテーブル単位 ただし、INSERT時は無視される  トランザクションサポートの対象外  インデックス機能が強力なため、読み取り性 能が高い ・BLOB列とTEXT列の先頭500文字に インデックス作成が可能 ・単語にインデックスを付けれる ・全文インデックスを付けれる ⇒イベント系のテーブル(INSERT、SELECTのみ するテーブル)に使うと効果が高いストレージ
  13. 13. 以下の特徴があります。  ロックは行単位 ただし、ギャップロック(テーブルロック) が可能  トランザクションサポートの対象  ANSI/ISO SQL標準のトランザクション分離レ ベルを備える  外部キー制約が使える  InnoDB-memchached-pluginを使うと、 InnoDBのデータにNoSQLでアクセスできるよ うになる(ver.5.6から正式サポート) ⇒DBを使って特殊なことをしない場合は、この ストレージエンジンを選んでおけば間違いはな い。
  14. 14. 以下の特徴があります。  MyISAMをRAM上に乗せている  データ量がRAMから溢れるとMyISAMに自動変 換される  MySQLやサーバ自体を再起動するとデータは 消える  クエリ性能はMyISAMの10倍程度と云われてい る ⇒参照オンリーのデータ(例:コード定義な ど不変のマスタデータ)を置くのに向いてい る。 SSDの低下価格化が進んでいるため、今後使 われることはなくなるかもしれない
  15. 15. ユーザはユーザ名 + ホストで管理されます 以下のユーザは別ユーザ扱いになります  sh-ogawa@localhost  sh-ogawa@company sh-ogawaは全世界共通です!な場合は以下のよう なユーザになります  sh-ogawa@’%’ ※sh-ogawa@localhostユーザがいると、 localhostからMySQLログインした場合、 ホストを%にした匿名ユーザは適応されません
  16. 16. MySQLはデータベース(ORACLEで云うスキーマ)に ユーザ毎のROLEを紐づけます。 CREATE DATABASE test; CREATE USER ‘ogawa’@’localhost’ identified by ‘oga', -> ‘super_ogawa’@’localhost’ identified by ‘oga'; GRANT SELECT ON test.* TO ‘ogawa'@'localhost'; GRANT ALL PRIVILEGES ON test.* TO ‘super_ogawa'@'localhost'; FLUSH PRIVILEGES;
  17. 17. レプリケーションとは、とあるDB(マスタ)の データを別のDB(ネットワーク上でも可のスレー ブ)に同期させる仕組みです。 MySQLのレプリケーションとしては、以下の特徴 があります。  マスタ側で発行したSQLをスレーブ側に送って実 行させることでデータの同期を計る  レプリケーションの対象は細かく指定できる (データベースまるまる、特定のテーブル、etc)  クエリを処理するスレッドとは別にレプリケー ション用のスレッドで処理されるため、処理系 に影響はほぼ出ることはない
  18. 18. MySQLのレプリケーションの仕組みは以下の図の とおり
  19. 19. レプリケーションの使いどころ  フェイルオーバーによるダウンタイムの大幅短縮化  負荷分散  データのバックアップ  MySQLのアップグレードのテスト
  20. 20. レプリケーションの弱点  初期構築時はちょっとしたことでスグ止まる  SQLを発行するため、実行タイミングで結果が変 わるような関数は使えない  ストアドファンクションなど対応していないもの があるため、標準のSQL以外を書くときは確認が 必要
  21. 21. MySQLで使えるレプリケーションの構成 マルチスレーブ 特徴 ・単純構造 ・スレーブ側の用途を自由に切り 替えられる ・スレーブをマスタに昇格させる のが楽
  22. 22. MySQLで使えるレプリケーションの構成 多段スレーブ 特徴 ・構造が複雑 ・レプリケーション自体の 負荷分散を行える ・マスタへの昇格はシナリオを 十分に考慮する必要がある
  23. 23. MySQLで使えるレプリケーションの構成 マルチソースレプリケーション (ver.5.7 or later) 特徴 ・複数マスタのデータをスレーブ が受け取れる(対象テーブルなど は異なる) ・マスタデータを分散し、スレー ブへ集約するため、柔軟な対応が 行える
  24. 24. MySQLで使えるレプリケーションの構成 マルチマスタレプリケーション (ver.5.8からの実装予定) 特徴 ・スレーブという考え方が無くな る ・同一行が更新されないインフラ 設計が必要になる ・物理的な距離の問題がある場合 に使える構成 (某SNSは恐らくこの構成)
  25. 25. マルチスレーブを例としたバックアップ計画
  26. 26. バックアップで必要なことは、 ただバックアップを採ることではなく、 リカバリ方法を十分に考慮した結果の手法でなく てはなりません。 リカバリシナリオにすべてが懸っているので腕の 見せ所ですよ!
  27. 27. 構成
  28. 28. リカバリ案 ・マスタ再起動 ・スレーブ再起動 ・マスタが壊れた場合 ・スレーブが壊れた場合 程度の考慮をして計画 今回の構成を例としたバックアップ計画
  29. 29. 参照DB再起動(スレーブの再起動)
  30. 30. 参照DB再起動(スレーブの再起動) 手順化すると以下 ①対象機サーバにinit.sqlが存在する場合、事前にリネームする。 ②対象機のslaveからmysqldumpにて対象DBをダンプする。 ・--dump-slave を指定し、対象機のslaveが参照しているマスタの情報を出力する ③対象機のslaveのmysqlプロセスを停止する。 ④対象機のslaveのmysqlプロセスを起動する。 ⑤②で出力したダンプファイルをロードする。 ⑥対象機のslaveのレプリケーションを開始する。
  31. 31. スレーブの復旧(スレーブから復旧) 手順化すると以下 ①稼動系のslaveからmysqldumpにて対象DBをダンプする。 ・--dump-slave を指定し、稼動系のslaveが参照しているマスタの情報を出力する ②稼動系サーバから対象機サーバへダンプファイルを転送する。 ・対象機サーバにinit.sqlが存在する場合、事前にリネームする。 ③対象機のslaveのmysqlプロセスを停止する。 ④対象機のslaveのmysqlプロセスを起動する。 ⑤②で転送されたダンプファイルをロードする。 ⑥対象機のslaveのレプリケーションを開始する。
  32. 32. スレーブの復旧(マスタから復旧) 手順化すると以下 ①更新DBからmysqldumpにて対象DBをダンプする。 ・--single-transaction を指定し、一貫性を保持したバックアップを取得する ・--master-data=1 を指定し、バイナリログのファイル名、開始位置を出力する ②更新DBサーバから対象の参照サーバへダンプファイルを転送する。 ・対象機サーバにinit.sqlが存在する場合、事前にリネームする。 ③対象機のslaveのmysqlプロセスを停止する。 ④対象機のslaveのmysqlプロセスを起動する。 ⑤②で転送されたダンプファイルをロードする。 ⑥対象機のslaveのレプリケーションを開始する。
  33. 33. マスタの復旧(スレーブから復旧) 手順化すると以下 ①更新DBのmysqlプロセスを停止する。 ②参照DB(両方)のレプリケーションを停止する。 ③参照DBからmysqldumpにて対象DBをダンプする。 ・--lock-all-tables を指定し、静止点を作る ④参照DBサーバから更新サーバへダンプファイルを転送する。 ⑤更新DB上でmysqlコマンドにてダンプファイルを適用する。 ⑥更新DBのbinlogのpositionを確認する。 ⑦参照DBのpositionを⑥で確認したpositionへ変更する。 ⑧参照DBのレプリケーションを開始する。 ※実施前に更新DBのバックアップを取得する ※復旧対象はレプリケーション対象のDBのみ
  34. 34. バックアップからの復旧(全台死亡時) 手順化すると以下 ①参照DB(両方)のレプリケーションを停止する。 ②バックアップ格納サーバから更新サーバへ日時バックアップダンプファイルを転送する。 ③更新DBの現在のbinlogのpositionを確認する。 ④更新DB上でmysqlコマンドにて日時バックアップダンプファイルを適用する。 ⑤更新DBからmysqldumpにて対象DBをダンプする。 ・--single-transaction を指定し、一貫性を保持したバックアップを取得する ・--master-data=1 を指定し、バイナリログのファイル名、開始位置を出力する ⑥更新DBサーバから参照DBサーバへダンプファイルを転送する。 ・参照DBサーバにinit.sqlが存在する場合、事前にリネームする。 ⑦⑥で転送されたダンプファイルをロードする。 ⑧対象機のslaveのレプリケーションを開始する。 ※⑥~⑧は参照DB1台ずつ実施する ※実施前に更新DBのバックアップを取得する
  35. 35. 処理を高速化するのは、 プログラムだけではありません! ミドルウェアのパラメータチューニングでも 処理を劇的に速くできる可能性があります。
  36. 36. MySQLにおけるチューニングの基本  スロークエリーを採ろう  SHOW STATUSコマンドで統計情報を確認する
  37. 37. MySQLにおけるチューニングの基本  スロークエリーを採ろう my.cnf(Windowsだとmy.ini)の mysqldセクションに以下を記述 [mysqld] #ログに出すクエリの実行秒数 long_query_time=1 log-slow-queries=/var/log/slow.log  SHOW STATUSコマンドで統計情報を確認する ・とりあえず mysql> SHOW STATUS LIKE ‘%disk%’; ・SELECT関連 mysql> SHOW STATUS LIKE ‘Select%’; mysql> SHOW STATUS LIKE ‘Handler_read_first’; ※上記に限らず全部に目を通すと良いですw
  38. 38. 統計情報確認しよう!と書いたけど、 これが統計情報だって知ったの 2016/9/6(昨日)ですw
  39. 39. SHOW STATUSから以下のパラメータを貪れば、 大体速くなります  innodb_log_buffer_size  binlog_cache_size  max_heap_table_size (MEMORYを使った場合)  tmp_table_size (TEMPORARY TABLEを使った場合)
  40. 40. 以下はデータベースの規模に合わせて、暗黙的 に大きく取ると良いパラメータ  innodb_buffer_pool_size  innodb_additional_mem_pool_size  innodb_autoextend_increment  innodb_log_buffer_size
  41. 41. その他、よく起きるエラーの対処  Open file limit error MySQLはファイルベースのアクセスのため、 ファイルディスクリプタが足らなくなること がままある。 OSの設定とopen_files_limitを両方変更する  ロングクエリでエラーになる 1MBのSQLなんて書かないだろうと思っていて も結構超えます。 (dumpやレプリケーションのSQLロード) max_allowed_packetを変更する
  42. 42. 初心者が遭遇する問題の紹介  大文字小文字の区別はプラットフォーム依存 Windows上で開発して、結合試験などでLinux に持っていくと起きるやつ Unix、Linux系は区別されます  データベースのデータが文字化け クライアントとサーバ、DBの文字コードが 合っていないと発生するやつ  知らない間にギャップロック その条件のデータがいるかどうか確認してか ら行ロックを取ろう

MySQLの社内勉強会資料1

Views

Total views

2,205

On Slideshare

0

From embeds

0

Number of embeds

6

Actions

Downloads

6

Shares

0

Comments

0

Likes

0

×