データベースを利用したテストを軽〜く実行したい時の味方: vimeo/php-mysql-engine / phperkaigi2021-lightning-talkPHPerKaigi2021でのLTの資料です。 https://fortee.jp/phperkaigi-2021/proposal/e1e0ebd8-d60c-42ed-b6e6-9a7602258d42 ★デモ動画 vimeo/php-mysql-engine を使ってテスト叩く様子 #phperkaigi - YouTube https://www.youtube.com/watch?v=PFNpLbBprb4
MySQLの物理削除によるパフォーマンスの悪化とその回避策について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめまして、Yahoo!ショッピングでシステム開発を担当している村上です。 Yahoo!ショッピングでは数億件にのぼる商品が日々更新されています。 今回はそれを支える巨大なDBの運用の中で遭遇したMySQLのアンチパターンと、回避した方法について紹介いたします。 特定のテーブルをJoinするとすごく遅くなる Yahoo!ショッピングでは商品を出品するためのツールがあります。 商品情報には「商品名」「価格」といった、任意で設定可能な項目のほか、「ブランド」「商品種別」など、製品ごとに入力する内容が決まっている項目を、マスター情報としてテーブルで管理しています。 このマスター情報を利用して、出品の際に入力情報が正確であるかどうか確か
最速で日本語環境のMySQL Dockerコンテナを建てる方法 - Qiita
はじめに MySQLの公式Dockerイメージは文字コードがlatin1だったり、タイムゾーンがTSだったり、localeがPOSIXだったりと、日本語環境で使うにはかなり不自由な感じです。 以下のdocker-compose.ymlを使うことで日本語環境をすぐに建てることが可能です。 最速で日本語環境を使いたい人はこちらをベースにしてみてください。 ファイル 以下のような構成を想定しています。 # Dockerfile_MySQL FROM mysql:5.6 # Set debian default locale to ja_JP.UTF-8 RUN apt-get update && \ apt-get install -y locales && \ rm -rf /var/lib/apt/lists/* && \ echo "ja_JP.UTF-8 UTF-8" > /etc/lo
MySQLテーブル設計のための、よく使うデータ型まとめ - プロエンジニア
１．１ テーブル（表）とは？ MySQLはリレーショナルデータベース（関係データベース）であり、複数のテーブル（表）とそのリレーション（関係）の集まりでデータベースが構成されています。 テーブルは縦の行（レコード）と横の列（カラム）からなる二次元の「表」であり、固定された列に対して、任意の数の行が追加される構造になっています。 １．２ テーブル定義の設計 テーブルの各列に格納できるデータの型やサイズなどの決まりごとを、テーブル定義と呼びます。リレーショナルデータベースを作る際には、このテーブル定義をまず決定する必要があります。このテーブル定義を記載した設計書のことを、「テーブル定義書」と呼びます。 またリレーショナルデータベースには、重複する行（レコード）を複数登録することはできません。そのためにデータを特定するための「キー」を設定します。
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 1. サーバーが完膚なきまでに死んでも MySQLのデータを失わないための表 技 それでも失ったら申し訳ない 2018/03/10 yoku0825 PHPerKaigi 2018 2. この話をしようと思った理由 みなさんは お題箱 というサービスをご存知ですか？ 俺はよく知りません（） Peing -質問箱- と別のものだということだけ知っています 1/87 3. この話をしようと思った理由 1月6日 19時頃にサーバ会社様（ConoHa様）にて発生 した障害が原因で、お題箱のデータベースサーバのシス テムが破損してしまい、本日までサービスが稼働できな い状況になっておりました。 サーバ会社の担当者様のご尽力もあり、1月9日 17時現 在、ひとまず復旧することができましたことをご報告い たします。 1/6 19時頃
MySQLレプリケーションをマスター無停止で再構築 | クラウド・AWSのIT技術者向けブログ SKYARCH BROADCASTING
MySQLレプリケーション障害時、マスターを無停止で再構築する手順。 ※マスターでdumpファイルを取得する際、DBのロックがかかるため、dumpに時間がかかる（DBサイズが大きい等）の場合は現実的ではありません。 （dumpの際、「--single-transaction」オプションを指定することでロックをかけずに実現できるようですが、こちらは未検証） 1.マスターにてdumpファイル取得 # mysqldump --all-databases --add-drop-table --master-data -p > test.db dumpの際、「--master-data」オプションを指定することでdump時のバイナリログ、ポジションの情報が付与されます。 上記オプションでdumpを取得した場合、dumpファイルに下記のような「CHANGE MASTER」のSQLが追加されます。 CH
MySQLのレプリケーション管理に関するメモ - Qiita
#!/bin/sh # Plugin to monitor the Seconds_Behind_Master of replication on a MySQL slave MYSQLOPTS=$mysqlopts MYSQL=${mysql:-mysql} if [ "$1" = "autoconf" ]; then $MYSQL --version 2>/dev/null >/dev/null if [ $? -eq 0 ] then $MYSQL $MYSQLOPTS -e '' 2>/dev/null >/dev/null if [ $? -eq 0 ] then echo yes exit 0 else echo "no (could not connect to mysql)" fi else echo "no (mysql not found)" fi exit 1 fi
MySQL(InnoDB)のテーブルから行を大量削除する場合に気をつけること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DBのデータを、月1などのバッチ処理やスポット処理でまとめて削除するときの注意点です。 いわゆる「MySQLあるある」の1つですが、実際に問題が発生すると、すぐには原因がわからず焦りますね。 2017/12/22追記： （古い記事なのに）まだまだある程度参照されているようですが、無駄に長くて回りくどい記事なので、要点（と若干の補足）だけ先に箇条書きしておきます。 MySQL(InnoDB)では、少量のデータページをサンプリングしてINDEX統計情報を生成し、オプティマイザのコスト計算などに使っています。 ある程度の行数分更新（INSER
Where狙いのキー、order by狙いのキー
11. I'm yoku0825 ● とある企業のDBA ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● 馬鹿だからかわいいわけじゃなくて、かわいい イルカがたまたまバカだった 12. はじめに ● サンプルデータは MySQLのサンプルデータ ベース(worldデータベース)からインデック スを全て取っ払ったものです ● http://dev.mysql.com/doc/index-other.html ● コードはgithubに上げてあります ● https://github.com/yoku0825/yapc_2014 ● すごく…ウンコードです… 13. はじめに ● 原則、MySQLは1つのテーブルにつき同時に1 つのインデックスしか使いません ● Index mergeとかあるけどアレは例外だし狙って やっても速くなる
monによるMySQLのデッドロック検知とロギング - FAT47の底辺インフラ議事録
更新が激しいDB（MySQL)でInnoDBのロック競合が発生し、アプリケーションサーバが詰まる状況が発生してしまいました。 障害監視はmonというアプリケーションで行なっているのですが、 今回はこのmonを使ってMySQLデッドロックの検知とロギングを行いたいと思います。 monについては下記の資料をご参照ください。 Mon, Muninによる楽々監視生活 デッドロック解析は下記サイトのSQLを利用しています。 MySQL InnoDBにおけるロック競合の解析手順 前提 ・MONのサーバは既に構築済みであること ・DBサーバはMySQL5.5であること（MySQL5.1+InnoDB pluginでも可） 〜〜〜 以下、監視対象のDBサーバにて作業 〜〜〜 SNMPインストール yum install net-snmplockを検知するスクリプト作成 vim /usr/local/sbi
PHPのmysqlndの圧縮プロトコルについてのメモ - hnwの日記
PHP+PDO+MySQLの環境では、PHP-MySQL間の通信についてzlibを使った圧縮プロトコルを利用することができます。この機能は、DBサーバのCPU利用率に十分余裕があり、かつPHP-MySQL間のネットワーク帯域が逼迫している状況で有用です。 MySQLの圧縮プロトコルとそのマニュアル PHP+MySQLの環境で、圧縮プロトコルは下記のようなコードで利用できます。 <?php $options = [ PDO::MYSQL_ATTR_COMPRESS => true ]; $db = new PDO($dsn, $user, $pass, $options); MySQLドライバとしてmysqlndを利用している場合*1、PHP 5.3.11（2012年4月リリース）以降であれば圧縮プロトコルに対応しています。このことはPHPマニュアルにも下記の通り記載があります。 PDO::
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.5 InnoDB のデッドロック
デッドロックとは、それぞれが他の必要なロックを保持しているために、異なるトランザクションを続行できない状況です。 両方のトランザクションがリソースが使用可能になるのを待機しているため、保持しているロックは解放されません。 デッドロックは、(UPDATE や SELECT ... FOR UPDATE などのステートメントを使用して) 複数のテーブルの行をトランザクションがロックするときに発生する可能性がありますが、逆の順序で発生します。 デッドロックは、このようなステートメントがインデックスレコードとギャップの範囲をロックし、各トランザクションが一部のロックを取得するけれども、タイミングの問題によりほかを取得しない場合にも発生することがあります。 デッドロックの例については、セクション15.7.5.1「InnoDB デッドロックの例」 を参照してください。 デッドロックの可能性を減らすには
MySQL の wait_timeout デフォルト値のワナ（接続モードによる値の違い） - Qiita
はじめに結論 wait_timeout のデフォルト値はクライアントの接続モードによって変わる。 接続が対話型の場合は interactive_timeout のグローバル変数値 接続が非対話型の場合は wait_timeout のグローバル変数値 （対話型である）mysql コマンドのプロンプトで確認した設定値が、（非対話型の）プログラムでも同じであるとは限らないので注意！ wait_timeout とは 接続のアイドルタイムアウト秒数。 この秒数クライアントからの反応がない場合、MySQL サーバはクライアントとの接続を切る。 接続が切られた状態でクエリを送った場合、"Lost connection to server during query" や "MySQL server has gone away" のエラーが発生する。 【ワナ】wait_timeout のデフォルト値（int
コンピュータは数値さえ正確に扱えない
(Last Updated On: 2018年8月13日)コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。 コンピューターは数値を正確に取り扱えない コンピューターは数値を正しく取り扱えるから便利なのでは？と思うかも知れません。「コンピューターは数値を正確に取り扱えない」これは動かし難い事実／制限です。 コンピューターが数値を正しく取り扱える条件が決まっています。条件の範囲外であれば正確に取り扱えません。 この問題によりロケットが爆発するといった事例もあります。 整数 最も解りやすいのは整数です。通常、整数は固定の記憶領域を持つ整数型で表現されます。32ビット整数、64ビット整数、という言葉はITシステムの開発者でなくても
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPerによるMySQLバージョンアップ 〜PHP7化の次〜 / PHP Conference Fukuoka 2018
http://radondb.io/
MySQL 8.0で憶えておいてほしいこと
GitHub - OOPS-ORG-PHP/mysql-extension-wrapper: Wrapper for mysql extension
CentOS-Dockerfiles/mysql/centos6 at master · CentOS/CentOS-Dockerfiles