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:
SmartHR が定期メンテナンスを始めた理由とやめる理由 - SmartHR Tech Blog
SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらで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
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
MySQL/MariaDB GTID レプリケーション詳細 - BizStationブログ
今回は、MySQL/MariaDB GTID レプリケーションの詳細を説明します。これは、Transactdによるレプリケーションセットアップ（修復）ツールを構築する際に調べたものです。 主に従来のバイナリログとポジションを使ったレプリケーションとGTIDによるレプリケーションの違いについて説明します。ある程度従来のレプリケーションのセットアップなどを理解していることを前提にしています。 Index なぜGTIDが必要なのか GTIDが活きるシナリオ GTIDによるポジションの解決 具体的なGTID GTIDを使うための設定 MariaDBでGTIDを使う 2つのGTIDポジションモード 新規セットアップ スレーブで、マスターを新マスターに切り替える ダウンしたマスターをスレーブ群に加える SQLスレッドのエラーを修復する MySQLでGTIDを使う GTIDセット GTIDセットの表現方
MySQLが統計情報を計算するタイミングで再起動してしまう - Qiita
対象バージョン MySQL 5.6.35, 5.7.17 現象 AWS より RDS 上の MySQL のうち 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, and 5.6.23 の各バージョンが廃止となるという連絡があり、その時点での最新バージョンである 5.6.35 にアップデートを実施した。 するとバージョンアップ後しばらくして以下のエラーが発生し、断続的に再起動を繰り返すようになってしまった。 （ログは一部改変しています） terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check 06:01:31 UTC - mysqld got signal 6 ; This could be because you h
なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳
この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
Big Sky :: Golang 1.8 でやってくる database/sql の変更点
golang 1.8 では database/sql に幾らかの新機能が追加されます。 キャンセル可能なクエリ データベースの型の可視化 複数の結果セット サーバへのping トランザクション分離レベル 名前付きパラメータ database/sql changes - Google ドキュメント https://docs.google.com/document/d/1F778e7ZSNiSmbju3jsEWzShcb8lIO4kDyfKDNm4PNd8/edit# 本記事では Golang 1.8 で追加される database/sql の変更内容と、go-sqlite3 での対応状況、利用する上での注意点等を書いていきます。 キャンセル可能なクエリ 実行が長いクエリがキャンセルできるようになります。各 API に Context のサフィックスが付いた物が提供されます。具体的には Que
Impossible WHERE noticed after reading const tables - 駄日記
動機 rails-footnotes をちょろりといじってインデックスを使わないクエリを使ったら警告っぽいものがでるようにしてみた。開発中のアプリでテストがてらに使ってもらったらインデックスを張っているのに「key」の値が設定されないクエリがあるよと報告が。extraに「Impossible WHERE noticed after reading const tables」ってメッセージがでている。なんじゃこれと思って調べた。 先に結果 あるクエリにてwhere条件の検索にユニークインデックスが使われることになった場合にデータがヒットしなかった場合に発生すると思われる（主キーも含む）。ノーマルのインデックスが使われた結果データがヒットしなかった場合は発生しない。 確認方法 テーブル作成 CREATE TABLE `books` ( `id` int(11) NOT NULL auto_in
Aurora 移行をキッカケに大きく改善したデータベース運用 | CyberAgent Developers Blog
はじめに クラウドファンディングプラットフォーム Makuake でウェブオペレーションをメインで担当している吉田慶章 ( @kakakakakku ) です．Developers Blog では，過去に『Well-Architected を目指した改善と組織文化への影響』を執筆したり，『「経営層を巻き込まないと開発組織は変わらない」――急成長するクラウドファンディングサービス「Makuake」エンジニアが社長と取り組んだこと』で組織変革をテーマにしたインタビューを受けたりしています．今回はサービスで使っているデータベースを MySQL 5.5 on EC2 から Amazon Aurora（以下，Aurora）に完全に移行した事例を紹介したいと思います．既にリリースをして約1ヶ月稼働していますが，大きな問題もなく安定稼働しています． 背景 例えばウェブサーバなど，既にスケールアウトが前提
DBのint枯渇を目の前にした僕らは - Qiita
MySQLのint型は符号付きで -2147483647〜2147483647 の範囲をサポートし、レコードを記録する際にこの範囲を超えて記録しようとするともちろんエラーとなります。 これは、長い運用の末にデータが膨大になり、ついにintのサポート範囲が枯渇寸前となった話です。 方針 DBはAWS Auroraを使用しており、アプリケーションはRailsで構築されています。RailsのMigrationはデフォルトでidカラムをAUTO INCREMENTのint型で作成します1。サービスの特徴としては他のサービスと比較すると高トラフィックに晒されるもので、DBに大量のログを記録する必要がありテーブルによっては1ヶ月で1億レコード以上記録されるものもあります。対処方法を検討し始めた時にはidは既に18億を超えており、やるべきことは対象のテーブルのidカラム、及びそのidを関連として保持して
MySQL の "0000-00-00" は NULL？ - sakaikの日々雑感～(T)編
数日前に、とみたまさひろさんのこんなツイートがありました。 なんだこれ？ MySQLこわい… mysql> SELECT * FROM x WHERE datetime IS NULL; datetime 0000-00-00 00:00:00— とみたまさひろ (@tmtms) 2015, 12月 17 @tmtms ちなみにその '0000-00-00' は、 IS NOT NULL のときには含まれないんですか？— 坂井 恵(SAKAI Kei) (@sakaik) 2015, 12月 17 MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.3.2 比較関数と演算子 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます" その後の t
MySQLでORDER BYをつけないときの並び順 - かみぽわーる
メリークリスマス！🎅🎄 このエントリはMySQL Casual Advent Calendar 2016の24日目です。 今日はこれの話です！ @eagletmt 実装と実行計画依存です(たとえばInnoDBで単一カラムのインデックスが使われた場合のsort orderはprimary keyになるはずです)— Ryuta Kamizono (@kamipo) December 4, 2016 @eagletmt すいません、すこし間違いがありました。もし hoge_id = ? のような絞り込みで単一カラムのインデックスが採用された場合はsort orderはprimary keyになるはずです。InnoDB前提なら基本的に実行計画依存です。— Ryuta Kamizono (@kamipo) December 4, 2016 @eagletmt MySQLでorder by無しのと
MySQLのMyRocksストレージエンジンの話を中の人から聞いた - Qiita
この記事はfreee Engineers Advent Calendar 2016の...っと、もう空きがないじゃないか! というわけで、急遽MySQL Casual Advent Calendar 2016の16日目としてお送りします。 MySQLエキスパートであるところのFacebook 松信嘉範さんによるMyRocks紹介プレゼンを聞く機会に恵まれたので、本人の許可を得てその内容を公開します。 経緯 松信さんと自分は以前に同じ会社で働いていた元同僚で、彼のデビュー作「現場で使える MySQL」の元となったDBマガジンの連載時にちょっとお手伝いした縁もあり、その後も交流が続いております。 今回は松信さんがちょいと日本に寄るというので食事に誘ったのですが、ついでなので私の現職 freee株式会社のオフィス見学に来てもらい、「せっかくだから何かしゃべって」という図々しいお願いをしたところ、
MySQLやSSDとかの話 その後 | GREE Engineering
こんにちわ。せじまです。 すべての基本は monitoring だと考えてるので、イマドキのウェアラブルデバイスいろいろ買っていろいろ計測してるんですが、最近のデジタルガジェット面白いなぁ２１世紀感パないと感心しまくってる今日このごろです。 ちょうど一年くらい前、 MySQL User Conference Tokyo 2015 で MySQLやSSDとかの話 前編を、 GREE Tech Talk #9 で MySQLやSSDとかの話 後編を、お話させていただきました。 その後どうなったの？ということで、後日談をまとめさせていただきました。（今回はMySQL成分それほどありません） 忙しい人のために三行でまとめると 以前の試みはわりとうまくいきました。 SSDの大容量化がさらに進んでますし、前回の経験を活かして、HDD積んだサーバの構成変更しました。 次のステージとしては、１ラックあたり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL using too much CPU
MySQLを割と一人で300台管理する技術
MySQLでタイムゾーンを設定する - Qiita
MHAの次を目指す mikasafabric for MySQL
