AWSが発表したクラウドネイティブなMySQL互換DB「Amazon Aurora」
連載バックナンバー re:Invent開催、3年目は全世界から1万3000人が参加 2014年11月11日から4日間、Amazon Web Services（以下、AWS）はアメリカのラスベガスにて年次イベント「re:Invent」を開催しました。今回で3回目、参加者は1万3千人と、規模は年々拡大しているようです。12日の基調講演ではAWSシニアバイスプレジデント Andy Jassy氏（写真）が登壇し、AWSがクラウドサービスでは規模や技術革新のペースなどで主導的な立場であることを強調していました。 発表で最も目立ったのは新しいデータベースエンジン「Amazon RDS for Aurora（以下、Aurora）」でした。大ざっぱにいうとAWS版MySQLです。 他にも「Amazon EC2 Container Service」やイベントドリブン型コンピュートサービス「AWS Lambd
MySQLユーザーのためのMySQLプロトコル入門 | GREE Engineering
さいきんMySQLユーザーのためのほげほげ、みたいなのが巷で流行しているようなので暇つぶしがてらに読んでいるMySQLプロトコルについて書いてみようかと思います。 いやまぁ、こういうプロトコルが読めるからといってすごく役立つということは全くないんですが、お酒の席のネタにできたり、高速、簡単、無料で試せるRDS MySQLからRedshiftへのデータ同期に出てくるようなreplicationをいじったツールとかのメンテが容易にできるかもしれなかったり、俺mysqldだぜ、みたいな事ができたり、なんかよくわからないけどちょっとハッピーになれそうですね！ 今日は手始めにMySQLとmysql clientがどういう通信をしているのか見ていき、実際にInitial Handshake Packetをparseしてみるところまでをやってみます。 Max OSXでのセットアップ 普段homebrew
【緊急】RDS for MySQL アップデートのお知らせ | DevelopersIO
はじめに こんにちは植木和樹です。本日10月17日付けでMySQL 5.5/5.6に対する脆弱性が発表されています。これはAWSのRDSも対象となっています。 AWS Developer Forums: 【参考日本語訳】MySQL 5.5 and 5.6 Security Advisory MySQL 5.5 and 5.6 Security Advisory 上記ページのリンク先にあるOracleの発表を読むと、「ユーザーパスワード認証なしに悪意のあるコードを実行できる」とあります。 訂正：2014/10/18 9:10 最初に公開した内容の一部に2点誤りがありました。 日本時間 10/18（土）に強制アップグレードされるインスタンスはPublicly Accessibleの設定に関係なく、セキュリティーグループが無条件解放になっているインスタンスが対象となります 日本時間 10/18（
オラクルはみんなが思っているほど悪者ではない | readwrite.jp
オープンソースに明るくない人々にとっては、オラクルのMySQL運用にまつわる騒動はあまりピンと来ないかもしれない。オラクルが2010年にサン・マイクロシステムズを買収した際、オープンソースの技術者たち（私もその一人だ）は、オラクルがMySQLを台無しにするのではないかと危惧した。オラクルが開発への投資を縮小したり、技術をクローズド化するような事態を想定したのである。しかしそんなことは起こらなかった。実際にはオラクルの管理の下、MySQLのパフォーマンスは劇的に改善され、コードの大部分もオープンのまま残されている。 それでもなお、オープンソースのコミュニティには未だにオラクルのMySQL運用をバッシングする人たちがいる。ちょっとオラクルが気の毒になるほどだ。 崩壊の危機にさらされたMySQLコミュニティー確かにオラクルはコミュニティに対してあまり友好的ではなかった。そして、同社に何十億ドルも
phpMyAdminを狙った攻撃観察 - ろば電子が詰まつてゐる
今日は、前々から準備していたセキュリティ勉強会が台風でポシャってしまった。あーあ、せっかく楽しみにしてたのに……最近ツイてないなぁ……。 で、なんだか不完全燃焼気味なので、ちょっと記事を書いてみる。前にちこっと見た、phpMyAdminへのアタック観察記というネタ。 phpMyAdminとは何か まぁ何を今さらという感じだけれども、phpMyAdminとはPHPで書かれたMySQLの管理ツール。GUIで分かりやすくデータベースが操作できるため初心者にとても人気のツールなのだが、残念ながら過去に大量の脆弱性が発見された(いや、現在形で「され続けている」と言った方が良いか)ため、日々世界中から不正アクセスの猛威にさらされている。 というわけで、Webサーバを立てていると、phpMyAdminが入っていないかとかスキャンしにくるアクセスがとても多い。この記事ではその辺のアタックを観察してみる。
MySQLの七年間修正されていないバグに七歳の誕生日ケーキが送られる
MySQL Bugs: #20786: mysqldump always includes AUTO_INCREMENT 2006年6月29日に報告されたMySQLのバグ#20786は、7年たった2013年6月29日になっても、なお修正されていない。そこで、このバグに対し七歳の誕生日ケーキが送られた。 バグの内容は、mysqldumpの出力が、--no-dataを指定しても、テーブル定義にAUTO_INCREMENT=xxxが含まれてしまうというものである。これはバックアップ目的にはふさわしいかもしれないが、開発目的のダンプにはふさわしくない。現状では、開発目的に使うには、ダンプ後のファイルを手動や、あるいはsedなどで書き換えなければならない。 期待される修正は、出力しないオプションを付け加えるか、--no-dataオプションが指定されたときは出力しないようにするというものだ。 変更自体
GOGA - 数式の夢とコンピュータの現実: ogr2ogrでGMLが読めない
なんだかGMLと格闘して疲れました。結局解決しなかったので回復不能です。 手元に日本語入りのGMLファイルがあり、これをQGISで読みたい。ただそれだけのことなんですが、かれこれ3時間ほど格闘して、なんの進展もなく。おそらく何かを間違えているのだと思いますが、解に辿り着くことができません。 まず、どうもQGISでは日本語ラベル入りのGMLを読めないのでは無いかという気がしてきました。ネット上のいくつかのドキュメントには読めると書いてあり、Shapefileですと日本語表示ができたのですが、GMLではどうあがいても無理。encodingもUTF-8, shift-jis, iso-2022-jp, euc-jpとそれぞれBOM有無や改行コードをかえて試してもダメです。 次に、Shapefileでは日本語の表示ができたので、GMLからShapefileに変換すればいいのではないかと思い、ogr
MySQL 緯度経度から該当するデータを範囲抽出する方法 | QK
ちょっと話が、前回のストアドプロシージャを使う話と前後してしまいますが・・・ iPhone, Android等のスマートフォンの爆発的な普及によって最近、位置情報を活用したアプリケーションが増えてきました。スマートフォンから出力される位置情報は、緯度、経度の情報だけなので、それに紐づく住所情報も取りたいですよね？（たぶん）、今回、MySQLを利用してGPSデータベースを作成してみました。情報があまりないので手順を含めいろいろと不足な部分もあるかと思いますが、検証ではまあまあ、期待される値がとれていると判断しましたのでｗ その手順を公開したいと思います。 位置情報の元ネタを探す じゃあ位置情報ってどこにあるの？実は、国土交通省にあったりするんです。しかも無償で自由な目的で利用できたります。知らなかった。 今回の説明では、位置情報データをダウンロードし、MySQLの地理情報テーブルに取り込み、
MySQL5.6で新しく追加された地理空間データ(GIS)の検索を実装してみた - matoyan’s blog
MySQL 5.6登場！！新機能速攻レビュー - 漢(オトコ)のコンピュータ道 を見ていたら、MySQL5.6の新機能の１つとして、こんな紹介が。 OpenGIS ジオメトリデータの比較において、これまではMBR（minimum bounding rectangle ≒ 近似的な長方形）に基づいた比較しか出来なかったのだが、ジオメトリの正確な形に基づいた比較ができるバージョンの関数が追加された。例えばMBRバージョンのContains()に対して、ST_Contains()というように、ST_というプレフィックスのついたものが正確な比較をするバージョンとなる。 つまり、（私が使ったことがない）postGISをわざわざ使わなくても、使い慣れたMySQLだけで「この部分の記録を探したい！」という要求に簡単に答えられそうです。さっそく機能を作ってみました。 実際は4/22から検討開始して、今日や
[MySQL]GeoMetry型を使う（指定範囲内のGeoMetry検索）: ソフトウェア開発技術者として逝きたかったです （ｃ）てるとみ
ソフトウェア開発のお仕事メモや、フェイキックIOLの手術体験談をマイペースに残していました。 もうあの頃へは戻れない・・・ [MySQL]GeoMetry型を使う（WKT形式を使ったSET/GET）で投稿した GeoMetry関連のMyメモです。 GeoMetry型のカラムには（当然ですが）空間情報が入っています。 例えば、学校などがわかりやすいでしょうか？ 「○○学校」のPOINT（位置）情報やPOLYGON（学区）情報を MySQLで管理できるわけです。 これらを検索条件としたいケースがおのずと出てきますが、 普通にWHERE条件とすることはできません。 専用関数を使う必要があります。 以下は、「最小外接矩形（MBR）における関係」より抜粋したものです。 ■MBRContains(g1,g2) 1 または 0 を返すことにより、g1 の最小外接矩形に g2 の最小外接矩形が 含まれてい
位置情報（緯度、経度）をMySQLのGeometry型で保存する
こんばんは。BS事業部隊員です。 今回は、位置情報(緯度、経度)の保存方法を紹介します。 これもまた得意のググりで見つけたものです。 ・位置情報サービスのはじめ方 ・Google MapsとMySQLの連携 MySQL(v5.0)のGeometry型.... 便利そう！とういうことで使ってみることにしました。 .... くわしいことは、先輩方のサイトを参考にしてください。詳しく載ってます。 ここでは、ポイントだけ。※ 例の位置情報は適当です。 １．Geometry型とは MySQL4.1以降で用意されている空間情報を扱うデータ型 ２．テーブル定義 対象カラムの型をGeometryとするだけ。 CREATE TABLE points ( point_id INT NOT NULL ,latlon GEOMETRY NOT NULL ,PRIMARY KEY (point_id) ,SPATI
MySQL TIPS 3 空間情報(geometry)を使って経度・緯度の検索を高速化する - イノベートな非日常
以下のようなピタゴラスの定理を使った指定した経度緯度に最も近いデータを取得するSQLは結構ありがちですが、CPU負荷が高く効率も悪いのでMySQLに標準搭載となった空間情報(geometry)を使ってみることにします。 SELECT * FROM loc ORDER BY power(abs(latitude - 緯度 ), 2) + power(abs(longitude - 緯度 ), 2) LIMIT 1 MySQLの空間情報(geometry)機能はPostGIS(Postgresカスタマイズ)に比べると貧弱なので、その為の工夫を行います。例えばここのとおりのままだと逆にSQLが遅くなります。 まずは、テーブル定義から 通常のテーブル CREATE TABLE IF NOT EXISTS `loc` ( `loc_id` int(11) NOT NULL auto_incremen
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
MySQL:auto_incrementが最大値まで達したとき – 仙人の心得
auto_incrementにしたカラムの型がintなら2147483647、bigintなら9223372036854775807がautoincrementの最大になる。 実際に最大値までauto_incrementを進めてみる。 ALTER TABLE table1 AUTO_INCREMENT= 2147483647; auto_incrementが最大値に達するともうそのテーブルには行を追加することはできなくなります。 oracleのシーケンスならCYCLEオプションがあるけどmysqlのauto_incrementにはそのような機能は無いらしい。 ではauto_incrementが最大値に達したとき、どうすればよいのか？ 単純に ALTER TABLE table1 AUTO_INCREMENT= 1; としても、table1に1より大きいキーが存在する限りauto_incre
varchar型のカラムで大文字小文字が区別されない（検索時のケース非依存） « Blog « MySQL Oracle データベース/システム開発 | トラックシステムズ TRACKSYSTEMS
しゃちょーです。 じゃんじゃんいきます。 今回もMySQLの超初心者Tips。 今回のネタは、MySQL自身がドキュメントでそう謳っているので仕様なんだけど、Oracle技術者の人にはあり得ない仕様らしくて、まさかそれがオプションだと思っていない人が多いので。 そんなこと言ったって仕様は仕様でしょ？しょうがないじゃん。 公式ドキュメントをちゃんと読めばわかるんだけど、みんな読まないよね。 気持ちわかりますよ。（でも読んだ方がいいよ） その2：varchar型のカラムで大文字小文字が区別されない（検索時のケース非依存） これはほぼ毎回聞かれるね。 MySQLのドキュメントでは「検索時のケース依存」（Case Sensitivity in Searches）という言い方をしている。 あまりにFAQなのでまさかと思って自分からは言わないが、 テストに入ったあたりで、 「wher
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CoffeeScriptベストプラクティス集 Node.jsアプリケーション編（3）
TechCrunch
Importing spatial data into MySQL — Web-GIS with GeoServer and GeoExt
国土数値情報の点データをmysqlにぶち込むプログラム
ソーシャルゲームのためのデータベース設計
