旧DBからdumpファイルを取得してRDSにインポートしようとしたら結構手間取った。 mysqldumpの実行 まずは旧環境にログインしてdumpファイルの出力 $ mysqldump -uuser_name -p -hhost_name --quick --single-transaction database_name > dump.sql
![MySQLのDBからAWSのRDSへデータをインポートする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba73648e3514906e2fff2b73c5ea5ab0f2e6d8b2/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9TXlTUUwlRTMlODElQUVEQiVFMyU4MSU4QiVFMyU4MiU4OUFXUyVFMyU4MSVBRVJEUyVFMyU4MSVCOCVFMyU4MyU4NyVFMyU4MyVCQyVFMyU4MiVCRiVFMyU4MiU5MiVFMyU4MiVBNCVFMyU4MyVCMyVFMyU4MyU5RCVFMyU4MyVCQyVFMyU4MyU4OCVFMyU4MSU5OSVFMyU4MiU4QiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZWRiMGRlMmYyNDAzNWU0NDQwYzRhNzJiYjBhYzU0MTI%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaGlrZXkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTI4YmY4ZjcxZjY5MDgwYWZjY2U1ZjcxMzBhMmExMmI0%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D44bff0dac84fd9cd09d589edf00da678)
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
MySQL Casual Advent Calendar 2016 - Qiitaの5日目の記事です。 AdventCalendar自体初参加でドキドキ。 トランザクションの開始は、BEGINしたときじゃない! MySQLでは、BEGIN(START TRANSACTION。長いので、以下、特筆すべき場合以外は「BEGIN」で)を宣言しても、内部的にはまだトランザクションを開始してません。 SQLを投げたタイミングで、トランザクション開始になります。 このとき、更新のない、FOR UPDATEもないSELECT文でも、トランザクションが開始されます。 なにそれきもい。 「AutoCommit=ON/OFF」による違い AutoCommit=ONのとき トランザクションはSQLを発行するたびにBEGIN/COMMITで完了し、ロールバックできません。 複数SQLを束ねて1つのトランザクション
MySQL 5.7.12 で突如登場した MySQL Shell とか X DevAPI とか X Protocol とかが面白そうだったので調べてみました。 Document Store とかも同じ文脈で語られてて、それぞれの用語が何を表してるのかややこしかったので、まずその辺から。 X Protocol mysqlx プラグインを使用することで追加されるサーバー/クライアントプロトコル。ポート番号は 33060。 詳細→ https://dev.mysql.com/doc/internals/en/x-protocol.html X DevAPI 各プログラミング言語用の新しいAPI。Document Store用のAPIも含む。今のところ、MySQL Shell JavaScript, MySQL Shell Python, Java, .Net, Node.js 用の API があ
Amazon Aurora 東京ローンチイベント 10/Nov/2015 発表資料 - RDS for MySQL から Aurora への移行に関する共有 事前に読んでおくべき資料 - Amazon re:Invent (DAT405) Amazon Aurora Deep Dive http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive - AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora - RDS for AuroraとRDS for MySQL5.6のPar
MySQL Performance Blogの翻訳。MySQL 5.7にはたくさんの改善や新機能が盛り込まれていますが、その中でも特に重要なものについてのまとめ。 ある日、Percona Supportの顧客とMySQL 5.7の新機能について議論する機会があったのですが、その後、重要な機能をまとめたリストがあったらいいんじゃないかと考えました。最新のMySQL 5.7.6 リリース予定版(RC)が、素晴らしい機能を詰め込んで公開されたばかり。これがMySQL 5.7の重要機能一覧です。 レプリケーション機能の拡充 MySQL 5.7の最重要機能の1つは、マルチソースレプリケーションでしょう。この機能では、スレーブに対して複数のマスタを指定でき、これまでのマスタが1台のみという制限がなくなります。同僚が書いたマルチソースレプリケーションについてのいいブログ記事(日本語訳)が役に立つはずです
外部キー便利!!! 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 Casual Talks vol.7 で LT をしてきました。 LT では Ruby(Rails) からカジュアルに Q4M を使える何かを作ったお話 として Q4M 周りのお話をしてきたのですが、そこで冒頭 "Q4M 使ってる人ー" と挙手を求めたら誰一人として手が挙がらなかったことに絶望してこのエントリーをしたためています。 (まーカジュアルだからなーカジュアルだから Q4M 使ってなくてもしょうがないからなー) (使ってないだけで知っている人はいたかもしれません、あと恥ずかしがり屋さん) このエントリーでは簡単な Q4M の使い方と特徴について説明していきます。 Q4M って Q4M は簡単に言うと DeNA の奥一穂さんが開発されている MySQL を使ったキューストレージです。 Q4M 自体は MySQL のストレージエンジンとして実装されているので、テーブル
最近なぜか MySQL を使う Ruby アプリを PostgreSQL に対応する羽目になっているのですが、今までほとんど MySQL 以外の RDBMS を触ってなかったので、色々ハマったりしたのでメモっときます。 なお PostgreSQL 歴が浅いので間違ってること書いてるかもしれません。 API プログラムから MySQL にアクセスするには Ruby/MySQL を使っていたのですが、PostgreSQL 用の API を新たに覚えるのは面倒だったので、Sequel を使って書き直しました。 mysql.query("select col1, col2 from table where col3='xxx'") ↓ db[:table].where(col3: 'xxx').select(:col1, :col2) …みたいな感じです。 今までプログラム中に突然 SQL が現れ
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ&コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。(何でもそうですけど)インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
Morgan Tocker MySQL Product Manager I work on the MySQL team at Oracle. My current position has me responsible for MySQL Server product management. I was previously community manager. In my previous post, I wrote about when data gets loaded in and out of cache. The goal of caching is to avoid having to perform disk IO, which if we are talking about hard drives, each operation is about 20 million t
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
MySQLサーバーをダウンさせた夜は数知れず。 その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。 サーバーがダウンしてしまう原因は何かと聞かれれば、「メモリです」と断言しましょう。 メモリ設定は諸刃の剣。 パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。 今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。 グローバルバッファとスレッドバッファ メモリの設定についてまず「グローバルバッファ」と「スレッドバッファ」について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。 グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するには グローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量 と
2012年6月のエントリの続きです。前回は同期レプリケーションによるネットワーク遅延のある環境において、MySQLの性能がどの程度低下するのかということを確認しました。その中でも特にsync_binlogが1に設定されている場合、性能が大きく低下するということが分かりました。参考としてAmazon RDSのマルチAZデプロイメントにおいては、性能と信頼性のトレードオフを考慮した結果、sync_binlogがデフォルトで0に設定されているということを調査しました。 タイトルでネタバレしていますが、MySQLの次期バージョン、MySQL 5.6でこのsync_binlog=1の性能が大きく改善します。前回と同じ負荷テストをMySQL 5.5.25からMySQL 5.6.6-labsに差し替えて行った結果を、以下に示します。 前回のMySQL 5.5.25と異なり、sync_binlog=1にお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く