最近の Kubernetes の動向は 1 日目の記事 で語られた通りです。 ついに v1.0.0 General Availability を迎え、 様々な場所で Kubernetes の話を聞くようになりました。 さて、本稿では一段階進んで、 Kubernetes が大体どんなものかは分かった、 でも実際どんな風に使われてるの?という疑念に対して、 Google の傘下である Youtube によって公開されている、 スケールする MySQL クラスタ Vitess を Kubernetes で試してみる事とします。 Vitess は Youtube が MySQL をスケールさせるために開発した Go 製の OSS です。 公式サイトの画像ですが、次のようなアーキテクチャとなっています。 それぞれのコンポーネントは以下の様な役割を担っています。 vtctl CLI から Vitess
ランキングを取得するSQL です。 同じスコアの場合は同じ順位にするなどの必要があるため結構面倒ですが、 下記SQL でイッパツで取得できます。 実際に携帯ゲームのランキングを取得するのに使用しているSQLです。 ranking テーブル CREATE TABLE ranking ( id bigint(20) NOT NULL auto_increment, name varchar(20) NOT NULL, score bigint(20) NOT NULL, ); SQL SELECT r1.name, r1.score, (SELECT count(r2.score) FROM ranking as r2 WHERE r2.score>r1.score)+1 as rank FROM ranking as r1 ORDER BY r1.score DESC LIMIT 10; r
待望のMySQL 5.6が正式にリリースされた。正式版の最初のバージョンは5.6.10である。コミュニティ版(MySQL Community Server)は下記のページからダウンロードできるので、ぜひ今すぐダウンロードして頂きたい。 MySQL Downloads MySQL 5.6のリリースにあわせて、GUIツールであるMySQL Workbenchやドライバも新しいバージョンがリリースされており、MySQL 5.6対応となっている。それらの周辺ソフトウェアもチェックして頂けると幸いである。 新機能について正式版の機能はリリース候補版の頃から特に変更はない。(リリース候補版まで到達したということは、正式版の機能セットは固まったということであり、大きな機能の変更はないことを意味するからだ。)なので新機能については、リリース候補版が出たときに書いたエントリを参照して頂きたい。 漢(オトコ)
morimorihoge 高校卒業後,学生をやりながらずっとWebアプリ開発に携わってきました.2010くらいまではPHP/Symfonyプログラマでしたが,それ以降のWeb開発はRailsほぼ一本に宗旨替えしました.開発とは別にサーバ構築・運用も10年以上やってきているので,要件定義から設計・実装・環境構築・運用まで一通り何でもこなせます.開発以外では季節により大学でWebサービス開発やプログラミング関連の非常勤講師もしており,技術の啓蒙・教育にも積極的に関わっています.最近はPM的な仕事が増えていますが,現役開発者としていつでも動ける程度にはコードもサーバも弄る日々を送っています.AWS 認定ソリューションアーキテクト – アソシエイトレベル取りました morimorihogeの書いた記事一覧へ
今やってるプロジェクトのテストケースとテストデータが結構な量あり、私のマシンで実行すると15分以上かかってしまいます。テスト環境は、 VMwareでCentOSをゲストOSにして、Windows7をホストOSにしてます。ノートPCは8Gメモリ、5400rpmのHDD。一番の原因は、5400rpmのHDDかつVMwareのゲストOSのディスクI/Oが遅いということです。そのためテストデータ(Fixture)をテストケースごとにリストアしてという動作に時間がかかります。 まずは、HDDをIntel SSDに変えてこれを10分以下に短縮できました。SSD快適すぎる。IntelSSDは移行ツールも無料で付いてるので便利です。 SSDで快適にはなりましたが、もっと速くがロマンというもの。また、SSDにディスクI/O発行しまくるのはSSDの寿命を縮めるので精神的に良くないです。(SSDはデータブロック
RailsのMigrationで:binaryとするとMySQLではblob型になる。 create_table :files do |t| t.column :data, :binary end MySQLでのblob型 型 サイズ TINYBLOB 256byte BLOB 64KB MEDIUMBLOB 16MB LONGBLOB 4GB Migrationでは:binaryしか選択肢がなくMySQLだとblob型として解釈される。 画像ファイルならば普通に大丈夫だけど他のファイルも扱うと苦しい。 SQLで直に属性を定義することでこの問題は解消する class AlterModifyLongblob < ActiveRecord::Migration def self.up execute("alter table table_name modify column_name long
MySQLを使っていて、サーバーの負荷は高くないのに接続できないクライアントが発生、状況を見ようとshow processlistするとunauthenticated userがたくさんいることがわかった。そのコネクションがあふれてmax connectionsに到達、接続できないクライアントがあるらしかった。 いろいろ調べてみるとクライアントのIPアドレスのDNS逆引きをしていて、その処理が追いつかなくなるとそうなるらしく、解決方法としては2つあった。 /etc/hostsでクライアントの名前解決をできるようにする /etc/my.cnfにskip-name-resolveを設定してMySQLをrestart /etc/hostsでの対策はお手軽だがメンテナンスが面倒な感じ。 skip-name-resolveのオプション付けていなかったっけ…と調べたら付いていないことが発覚。/etc/
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ!!などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい!! 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake(MySQL 5.5以降)やconfigure(MySQL 5.1以前)にかかる時間は除いてある。だがそれでも速い。
Mysqlにてlockしているプロセスを確認する方法と削除する方法 ■lockの確認 State欄にて「Locked」「updating」等の状態を確認できる。
ミツバチワークスのエンジニアは、「月間57億PV」という巨大なトラフィックをさばくため、さまざまな技術を駆使してインフラを構築している。主と副の2本立てでデータベースを運用し、300台のサーバを使いながら「負荷の限界」に挑むエンジニアに、技術ノウハウを聞く。 ミツバチワークスが運営するケータイブログサービス「DECOLOG」は、異色のサービスである。10代後半から20代前半の女性に最も人気のあるケータイブログサービスで、「デコメール」などを利用して、かわいくカラフルなブログを作成できる。広告基準を厳しくすることで女性ユーザーにも不安なく使ってもらえるような安心感を作り出し、口コミだけでじわじわとアクセス数を伸ばしてきた。 結果、2010年7月実績で月間57億PV(ページビュー)超、想定800万UU(ユニークユーザー)、会員登録者数180万件と、ケータイブログサイトでは国内最大のサービスとし
環境: MySQL 5.0 (マニュアルを見る限りバージョン5.1でも事情は同じ) 某CMSにて、1つのテーブルにTEXT型のフィールドをたくさん作ったところ、次のようなエラーが出てデータを保存できなくなった。 Got error 139 from storage engine このエラーメッセージで検索すればいろいろと情報が出てくるが、こういうことらしい: InnoDBの行サイズの上限はページサイズの約半分で、デフォルトでは約8000バイト 可変長カラム(VARBINARY, VARCHAR, BLOB, TEXT)のデータは行の外部に保存されるが、先頭の768バイトだけは行の内部に保存される よって例えば一つのテーブルに11個のTEXT型フィールドを作り、それぞれに768バイト以上のデータを入れようとすると、768*11=8448 > 8000 なので保存できない ページサイズは8〜6
1. 概要 MySQLでレプリケーションを行っているとMasterにバイナリログが溜っていきディスクを圧迫するので定期的に削除してやる必要がある。 2. 手順 2.1 レプリケーション状態の確認 まず、どこまでバイナリログを削除してよいかを調べる。 Slave側でSHOW SLAVE STATUSを実行し、Slaveがバイナリログをどこまで読み取っているかを調べる。「Master_Log_File」が現在参照中のバイナリログ。以下の例ではskylancer00-bin.000084を使用していることになるので、skylancer00-bin.000083まで削除してしまってよいことになる。Slaveが複数いる場合は、全Slaveについて確認を行う。 mysql> SHOW SLAVE STATUS \G *************************** 1. row ********
----------------------------------------------------------------------------- HandlerSocket plugin for MySQL Copyright (c) 2010 DeNA Co.,Ltd. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditio
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く