こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
IT 基盤部の石川です。 IT 基盤部ではオンプレ、パブリッククラウド問わず多くのインスタンスを管理していますが、その中で “Multi Instance” と呼んでいる独自のインスタンス管理方法があります。今回は、その Multi Instance とは何か、Multi Instance を使った MySQL サーバのコスト最適化方法を話します。ちなみに、この原稿は re:Invent 2019 へ行く飛行機の中で書いています。 Multi Instance とは Multi Instance とは、1 つのインスタンスに複数の IP アドレスを紐付け、あたかも複数のインスタンスのように振る舞うインスタンスのことを部内ではそう呼んでいます。Multi Instance の起源はオンプレ時代にさかのぼります。オンプレをメインで使用していた頃は、用途ごとに適切なスペックの機材をその都度調達す
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
MySQL 8.0.17でついにCloneプラグインが入った
TL;DR MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい このへんを読んでおくのが良さげ MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.13 Clone Plugin Limitations mysql
MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関
MariaDB を production 環境で利用する際はほぼ例外なくなんらかの高可用性(High Availability, HA)構成を組むと思います。MariaDBで最も高い可用性が要求される場合は自動フェールオーバ、multi-master synchronous replication の Galera Clusterを利用することになるかと思います。 なお、Azure では MariaDB のデータベースプロキシ MaxScale x 2ノード + 3ノード構成の Galera Clusterを2時間体験することができるようになっているようです。 https://mariadb.com/kb/en/library/mariadb-tx-cluster-in-azure-quick-guide/ https://azuremarketplace.microsoft.com/ja
本稿ではデータベースサーバー MySQL Community Server 5.6 を yum を利用して CentOS 7 にインストールする手順について解説します。 事前準備 CentOS 7 には mariaDB という MySQL 互換のデータベースサーバーがデフォルトでインストールされている場合がありますので、これからインストールする MySQL と競合を起こさないように削除しておきましょう。 つぎのコマンドのように mariaDB 本体とデータフォルダを削除しておきます。 # yum remove mariadb-libs # rm -rf /var/lib/mysql/ MySQL 公式 yum リポジトリの追加 RHEL系の Linux は、パッケージ管理ツール yum を利用して様々なソフトウェアをインストールすることができますが、CentOS 7 からは標準リポジトリで
どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。（もちろん、きっかは自分がドツボにはまったから） ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 （というか、これが問題なく読めて理解できる人はこの記事読む必要ない….） 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
5. 2006年 2006.8 Peter Zaitsev、Vadim Tkachenko が MySQL AB(High Performance Group)離籍して Percona 設立 ※当時、S商情報システムのS原さんがMySQLの性能の将来を危惧していた。 ※S原さんは日本に有力なハッカーが居ないことも当時危惧していたと思う。 （世界のMySQLコミュニティにおける日本ユーザーのプレゼンスが低くなってしまうから） 多少影響を受けた。 2006.8 Bug#15815: Very poor performance with multiple queries running concurrently (http://www.mysqlperformanceblog.com/2006/07/28/returning-to-innodb-scalability/) の議論に参加 ※これが
MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に 前バージョンのバージョン番号は5.7で、本バージョンが8.0になったのは、過去のバージョン番号で6が使われたことがあったというMySQL のバージョンの都合や、MySQL Clusterがバージョン7であることなどを考慮したためとされています。 MySQL 8.0では、大幅な性能向上、JSONデータに対応したNoSQL機能の搭載、地理情報の対応、ロールによるユーザー権限など、さまざまな改善が行われています。 性能が最大で2倍に MySQL 8.0では、MySQL 5.7と比較してユーザー数が増えた場合に最大で約2倍ほどの大きな性能向上を実現しています。下記は読み込み性能の比較です。 読み込みだけでなく書き込み性能も向上しており、これはInnoDBでREDOログ
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
Oracle DatabaseとMySQLの機能の違いを比較表で理解する：実践 OSSデータベース移行プロジェクト（終）（1/2 ページ） 本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、移行設計を実施するに当たり把握しておきたい、Oracle DatabaseとMySQLの機能の違いについて説明します。 商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けする本連載「実践 OSSデータベース移行プロジェクト」。前回までは、株式会社豊洲部品（仮名）社内システムの移行事例を用いてさまざまな観点より移行コストの評価を実施しました。 本稿では、個々の移行事例から離れて、移行設計を実施するに当たり把握して
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
スレーブのスレッド スレーブには2つのスレッドが存在しました。 I/OスレッドとSQLスレッドです。 I/Oスレッド マスタの更新ログを取りに行き、スレーブにリレーログとして保存します。DBの更新はしません。 SQLスレッド リレーログを読み込み、SQLを実行してDBを更新します。 それぞれが別に走っているところもポイントです。別に走っているので、スレッドを停止する場合はI/Oスレッドを止めてからSQLスレッドを止める必要があります。そうしないとリレーログだけ残ってしまう可能性があるからです。 レプリケーションの設定手順 わかりやすいサイト様があったのでどうぞ http://qiita.com/shotaTsuge/items/83e4387d6c8488677e17 レプリケーションの切替手順 GTIDを使用しない場合のレプリケーション例を挙げて説明します。以下のDBサーバを用意しました
MySQLインストール及び初期設定 yumで必要なパッケージをインストールして、MySQLのrootユーザーのパスワードを設定します 【Master, Slave共通】 mysqlの関連パッケージをyumでインストールします # yum install mysql mysql-server MySQLのrootユーザーのパスワード設定及びサービスの自動起動を設定します。rootのパスワードですが「momo1234」と設定しています # /etc/init.d/mysqld start # /usr/bin/mysqladmin -u root password 'momo1234' # chkconfig mysqld on MySQLのレプリケーションユーザー設定 レプリケーションで使用するレプリケーション用アカウントを設定します。アカウント名は「repl」としパスワード「mikan32
#経緯 とある勉強会の内容の復習＆整理 #タイトル インストール・アーキテクチャ基礎編 レプリケーション編 ←今回はこちら バックアップ編 チューニング基礎編 #レプリケーション編 アジェンダ レプリケーションとは レプリケーションの仕組み レプリケーションの種類 レプリケーションの設定方法 バイナリログの管理方法 その他の考慮事項 参考情報 #1. レプリケーションとは ##1.1. 基礎知識 データの複製（レプリカ）を別のサーバにモテる機能 MySQLの標準機能で、多数のWebサイト等で利用されている － シンプルな設定で利用可能 － マスター → スレーブ構成 ##1.2. マスタースレーブ構成 サーバはマスター、スレーブまたは両方になれる マスターサーバ － データを変更 － 変更内容をスレーブに転送 － マスターは複数のスレーブを持てる スレーブサーバ － マスターでの変更内容を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
