utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
株式会社ソフトエイジェンシー – MySQL, Qooker, VG-Sync, IP-PBX | ライセンス早分かり
MySQLのライセンスはサーバ/クライアントの区別なく、GPL(GNU General Public License)か、コマーシャルライセンスのいずれかの形態を選択するデュアルライセンス方式です。 もしあなたがMySQLを使ったソフトウェアを開発し、他の人に配布しようとしている場合、それは有料、無料、評価版、製品版にかかわらず、あなたの開発したソフトウエアをGNU GPLに従い配布するつもりがなければ、コマーシャルライセンスの購入が必要となります。 ※ GNU GPL(GNU General Public License)とは、フリーソフトウエア財団の一般公衆利用許諾契約書のことで、ソフトウエアの共有と改変を自由に保証するものです。 ※ GPLを選択する場合、目的を問わず、開発されたものはGPLとしてソースコードと共に配布しなければなりません。また再配布,変更,コピーを禁止してはなりませ
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
MySQL 8.0.0 Development Milestone Release登場！！
先月、詳解MySQL 5.7を発刊したばかりであるが、MySQL 5.7自体は去年の10月にリリースされたバージョンである。それから約1年弱、MySQLは開発の手を緩めること無く日々改良を重ねている。 そう、MySQL 8.0の登場である。 現在はDevelopment Milestone Release（通称DMR）という状態なので、まだ正式版における機能が固まっている段階ではないという点には注意して欲しい。MySQLの開発プロセスでは、DMRをリリースするごとにその段階で成熟した機能をマージする。DMRを何度かリリースした後に、キリの良いところでリリース候補版となって正式版で追加される機能が一応確定し、その後バグ修正を経て正式版（GA版）がリリースされる予定となっている。詳しくはMySQLのマニュアルを参照して欲しい。 バージョン8.0!!5.7の次は誰もが5.8だと思っていただろう・
MySQL5.6 .mylogin.cnfで遊んでみる
What's newの頭に書かれているのに誰もやってなさそうなので遊んでみる。 遊んでみるとは言っても、$HOME/.my.cnfにuser=/password=で書くのとやってることは変わらない。 今まで平文で書くのが嫌で特にやってなかったけど、これならやっても良いかなーという風情。 http://dev.mysql.com/doc/refman/5.6/en/mysql-config-editor.html $ mysql_config_editor set --user=tpcc --password Enter password: <パスワード手入力> $ mysql_config_editor print --all [client] user = tpcc password = ***** とまあこの通り記録される。 何も指定しないとclientセクションに記録されるけれど、セ
我々(主語が大きい)は何故MySQLで外部キーを使わないのか
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
MySQLの設定ファイル my.cnf をgithubにて公開しました & チューニングポイントの紹介 - blog.nomadscafe.jp
YAPC::Asiaのスライドで予告していた通り、実際に弊社のいくつかのサービスで使っている my.cnf を公開しました。 github: https://github.com/kazeburo/mysetup/tree/master/mysql 今回、公開した理由はMySQl Beginners Talksの発表の中でも触れている通りです。MySQLのソースコード中に含まれるサンプルのmy.cnfが最近のサーバハードウェアや運用に合わなくなって来ているという状況で、自分の設定にイマイチ自信が持てていない人は少なくないはず。そこで各社秘伝のタレ的な my.cnf をOpen & Shareすることで、モダンなmy.cnfを作り上げる事ができるんじゃないかという考えの下、今回 github にて公開しました。 ファイルは4つあり、それぞれ MySQL 4.0、5.1、5.5、そしてテスト中
Pythonで作られた便利なコマンドラインツール MySQL Utilities
MySQL Utilitiesならではの注意点 MySQL Utilitiesは従来のコマンドラインツール群とは違い、以下のような記述で接続先を指定します。 これは、従来のコマンドラインツール群が主に1つのMySQLサーバーを対象として動作するものなのに対して、MySQL Utilitiesは2つ以上のMySQLサーバーを対象として動作するものが多いため、このような記法になっています。 [MySQL Utilitiesの記法] --server=ユーザ名:パスワード@ホスト名:ポート番号 [MySQL コマンドラインツール群の記法] --user=ユーザ名 --password=パスワード --host=ホスト名 --port=ポート番号 なおWindows環境ではローカルホストとしてlocalhostと127.0.0.1のどちらを指定しても同じですが、LinuxやUNIXではホスト名に対
バイナリログ(mysql-bin)の運用について - メモとかそんな感じなやつ
サーバ運用における基本的な監視にディスクの容量監視があります。 ディスクの使用率が100%になるとサービスに影響がでるのはもちろんですが、 サーバ管理者として100%になるまで気が付かないと恥ずかしかったりします。 (落ちた原因はなんだよ！！！ → デ、ディスクの使用率が100%です(///)ってなる) なのでだいたい90%を閾値にディスクの使用率監視をしているのですが、 アラートを検知してそれがMySQLの動いてるサーバだとバイナリログの肥大化を疑います。 バイナリログは更新系のログが記録されますが、放っておくと際限なく増えるので ディスク逼迫の原因になってしまいます。 ので不要なログは定期的に削除したりしますが、そのまとめ。 expire_logs_days my.cnfに [mysqld] expire_logs_days=10と設定したり、set global で mysql> s
萌えキャラとは何だったのか - トランザクション
トランザクションってなーに？mix3です 同時更新処理 スレーブ遅延のときにSELECT > UPDATEで古い情報をもとにUPDATEしてしまうと不整合が発生すると書きましたが、 たとえば同じ行を複数で同時にSELECT > UPDATEすると同じように不整合が発生することがあります。 AがT1からSELECT BがT1からSELECT AがT1をUPDATE BがT1をUPDATE このような順序で更新がかかると、BがAの更新を上書きしてしまうため、実質Aの更新が無かった事になってしまいます。 これも更新がアトミックであれば発生しないので可能であればアトミックな更新にするのが良いですが、更新が複数ある場合はそういった変更も出来ません。 そんなときこそトランザクション。そんなふうに考えていた時期が僕にもありました。 で、そういうときはトランザクションを使う物だと思っていました。トランザク
クソクエリを燻り出す - Studio3104::BLOG.new
非効率なクエリが投げられてMySQLサーバが悲鳴をあげることがあります。 DBAは、そんなときに「こんなクソクエリ投げてんじゃねーよ(ノ｀Д´)ノ彡┻━┻」と言えるようにダメクエリを探し出せるようにしておく必要があります。 スロークエリログ スロークエリログを出力するようにする my.cnfにこのように書いておくと、実行に指定時間以上を要したクエリが指定ファイルに出力されるようになります。 ※MySQL5.0以前のバージョンは書き方が異なるので注意 この例では、「実行に0.5秒以上かかったクエリを/var/log/mysql/slow.logに吐く」ようになります。 [mysqld] slow_query_log=1 slow_query_log_file=/var/log/mysql/slow.log long_query_time=0.5 漢(オトコ)のコンピュータ道: MySQL 5
MySQLでstatement-based replicationを使っている場合のtrigger, function, procedureの扱い - 愛と勇気と缶ビール
row-basedなreplicationの場合はreplicationの対象が文字通りrow=dataであるため特にtrigger, function, procedureの動作について懸念点はないと思われます。でも、MySQLで既に多くの人が使っているであろうstatement-basedなreplicationの場合はどうなるの？masterだけで実行されるの？それとも両方で実行されるの？両方で実行されるとしたらデータの整合性とかはどうなるの？ これらの疑問への答えはだいたい以下のドキュメントに書いてあるようですが、日本語版は「お前は何を言っているんだ」という部分が多々あり、英語版を読んでもあまり実際の動作がイメージできなかったので確認を兼ねて自分で試すことにしました。 http://dev.mysql.com/doc/refman/5.1/en/replication-featur
check_mysql_queryで範囲指定 - InnoDBの空き容量を監視する - （ひ）メモ
なぎおす！ な！なんとなく〜 ぎ！ギャグでごまかそうと〜 お！おっさんどもが〜 す！すべってゆく〜 ハイ！ガショー！！ Nagios (nagios-plugins) にcheck_mysql_queryというのがあります。 http://nagiosplugins.org/man/check_mysql_query MySQLに任意のクエリを発行して、その結果を元に監視の可否をするプラグインです。 「SELECT 1」とかを発行して期待した応答が返ってくるかとか死活監視に使えますが、結果が数値の場合、範囲内/外にあるかどうかの監視もできます。 例えば、(innodb_file_per_tableしていない場合の)InnoDBの空き容量を調べる設定はこんな感じになります。 前提: "infra"というデータベースに、InnoDBの"health"というテーブルがある MySQLのユーザー"
日々の覚書: MySQL5.5系のチェンジバッファのバグ
2024 ( 18 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 4月 ( 1 ) 3月 ( 2 ) 2020 ( 42 ) 12月 ( 3 ) 10月 ( 2 ) 9月 ( 4 ) 8月 ( 3 ) 7月 ( 4 ) 6月 ( 6
[MySQL] ibdata1のサイズを削減する手順 [InnoDB] | oshiire*BLOG
我が家では”Zabbix“や”WordPress“を利用していて、そのバックエンドのDBとして、”MySQL“を利用しています。 立ち上げに特に設計もしているわけでもなく、何となく使い始めたために、知らぬ間にいろいろと課題が出てきました。稼働に影響を与えているものとして 2つあります。 MySQLのdatadir直下にある ibdata1がディスクそのものを圧迫している 一つのサーバにいろいろと同居している上、SMPも使えず 32bitによるメモリ制限もあって、MySQLがボトルネックになっている 何も考えずに作り始めるってのは、ホント問題ですねぇ。アーキテクトとしては最低です。まぁ、作り始めたころはまだアーキテクトではなかったので、良しとしましょう [I]よろしくない この二つの課題の内、一つ目「ibdata1ファイルがディスクそのものを圧迫している」問題について、先にまず対処しました
![[MySQL] ibdata1のサイズを削減する手順 [InnoDB] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/8d71ff5111e05619a10d29bb40d7aebaa75c8fbc/height=288;version=1;width=512/https%3A%2F%2Fs0.wp.com%2Fi%2Fblank.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google
MySQLバックアップの基本
http://blog.inouetakuya.info/entry/20130320/1363776504
ZABBIXでMySQLを監視する：びぼうろぐ：So-netブログ
conma.me
