"Портирование Web SDK с JS на TS" Петров Григорий, Voximplantit-people
"Портирование Web SDK с JS на TS" Петров Григорий, Voximplantit-people
攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 米Oracle傘下のオープンソースデータベース「MySQL」に未解決の脆弱性が見つかったとして、セキュリティ研究者が9月12日に概略やコンセプト実証コードを公開した。サイバー攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 研究者のDawid Golunski氏が公開した情報によれば、MySQLの脆弱性は複数発見され、、中でも特に深刻な1件については、リモートの攻撃者がMySQLの設定ファイルに不正な内容を仕込むSQLインジェクション攻撃に利用される恐れがある。 この脆弱性は、MySQLの最新版を含む5.7系、5.6系、5.5系の全バージョンに、デフォルトの状態で存在する。現時点でOracle MySQLサーバの脆弱性修正パッチは存在
Google、MySQL互換の第二世代「Cloud SQL」正式リリース。ベンチマークを公開し、Amazon Auroraより高速だとアピール Googleは、Google Cloud Platformで提供しているマネージドサービスのMySQL互換データベースである「Cloud SQL」を正式版としてリリースしました。 Cloud SQLは2011年に発表され、2015年12月には性能を強化した第二世代が登場、最大10テラバイトのデータ容量とインスタンスあたり最大104GBメモリを提供し、最大2万IOPSの性能に達すると説明されていました。 正式版リリースにあたり、同社はブログ「Google Cloud Platform Blog: Cloud SQL Second Generation performance and feature deep dive」で競合となるAmazonクラウド
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ&コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。(何でもそうですけど)インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 本発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
昨日のエントリ「SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?」にて、認証回避の攻撃文字列が5文字にできる(「'OR'1」)ことを示しましたが、@masa141421356さんと、やまざきさん(お二人とも拙著のレビュアーです)から、idとpwdにまたがった攻撃例を示していただきました。やまざきさんの例は、MySQL限定ながら、なんと3文字です。これはすごい。 @masa141421356さんの攻撃例 @masa141421356さんのツイートを引用します。 @ockeghem 大抵のDBでid=''OR' AND pwd='>' ' が通ると思います(id側に「'OR」, pwd側に「>' 」で6文字)。長さ0の文字列がNULL扱いされないDBなら最後のスペースを消して5文字です。 — masa141421356 (@masa141421356) June
2012年7月1日のうるう秒のあとに、MySQLやJavaなどのCPU使用率が高騰する事象が報告されています。 CPU %user %nice %system %iowait %steal %idle 08時30分01秒 all 0.02 0.00 0.02 0.04 0.00 99.91 08時40分01秒 all 0.02 0.00 0.02 0.08 0.00 99.88 08時50分01秒 all 0.02 0.00 0.02 0.03 0.00 99.92 09時00分01秒 all 0.11 0.00 0.13 0.04 0.00 99.72 09時10分01秒 all 23.02 0.00 29.09 0.11 0.00 47.78 09時20分01秒 all 23.11 0.00 29.08 0.06 0.00 47.75 09時30分01秒 all 22.85 0.00
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
しわっす!DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい>< MySQL がおかしい! 03:14 hidek: なんかエラー出まくってるんだけど! 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね?ね?ね?こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう?既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
MySQL の勉強をせずにフレームワーク等で SQL を書かずに Web サイトを構築していました。データ数も2万件程度でしたので、そこまで困ることはありませんでしたが、今回100万弱の商品データを扱う機会ができたので、MySQL のチューニングや発行する SQL について見直す機会がありました。 この記事では MySQL を高速化するのに行った対策など勉強したものを自分用にメモしておきました。 条件式で比較するカラムにインデックスを使用して高速化 商品コードで存在しない商品を見つけて、商品をDBに登録するという処理を行っている場合、4万件超えたころから処理に2秒以上かかるようになってきます。12万件超えた頃には10秒程度かかるようになってしまいましたが、商品コードのフィールドに対してカラムインデックスを貼ることで0.2秒に短縮することができました。 MySQL のリファレンスにも以下のよ
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
4月11日から米サンタクララで行われた「MySQL Conference & Expo 2011」。このイベントでDeNAの松信嘉範(まつのぶよしのり)氏が、同社の大規模なMySQLの運用を支えている技術とツールについてのセッション「Automated, Non-Stop MySQL Operations and Failover」を行いました。 プレゼンテーションの中で、社内で利用しているフェイルオーバーの自動化ツールをオープンソース化することにも触れています(英語のドキュメントも作成中とのこと)。 MySQLの大規模運用における自動フェイルオーバーは、特にクラウドでのMySQLの利用が増えるにつれてニーズが高まる分野と思われます。セッションのスライドが公開されていますので、そのポイントを紹介していきます。 自動化されたノンストップなMySQLの運用 ソーシャルゲームでは高可用性が強く求
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く