メディア統括本部 サービスリライアビリティグループ(SRG)の鬼海雄太(@fat47)です。 #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、MySQ
皆さんはMySQLからデータを論理バックアップする際にどんなコマンドを使っているでしょうか? 5.7より前のバージョンを利用していた場合は、第15回 mysqldumpを使ってバックアップするや第62回 MySQLのクライアントプログラムいろいろ[その2]で紹介したmysqldumpを使用していることが多いのではないかなとは思います。 今回は、MySQL 5.7.8から導入されたmysqlpump(誤字じゃないです)について紹介してきます。 検証環境 今回は、第125回 phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、GitHubのわたしのレポジトリにサンプルコードとして置いてあるので、気軽に試したい方はgit cloneして試してみてください。試すにはdockerとdocker-com
竈門禰󠄀豆子をMySQL5.6のテーブルにinsertしようとすると正しく格納できず、竈門禰となってしまうケースがあるという話を聞き、調べてみました。 実践 まずは試しにやってみます。 mysql> show create table verification\G *************************** 1. row *************************** Table: verification Create Table: CREATE TABLE `verification` ( `name` varchar(100) COLLATE utf8_bin DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin 1 row in set (0.01 sec) mysql> inse
はじめに 異なるRDBMS間で、データを転送する業務が発生しました。 調べている中で、今更ながらEmbulkを知ったのでその使い方のメモです。 今回は、MySQL -> PostgreSQLのデータロードを行います。 Embulkとは 公式のGitHubより Embulk is a parallel bulk data loader that helps data transfer between various storages, databases, NoSQL and cloud services. Embulk supports plugins to add functions. You can share the plugins to keep your custom scripts readable, maintainable, and reusable. ザックリ説明すると
このページは、WordPress のデータベースの文字コードと照合順序の調査内容を記載するページです。 注意 このページに記載してある内容は WordPress 5.3.2 時点の内容です。将来のバージョンでは仕様が変更されているかもしれません。 文字コード おおまかな条件 文字コード DB_CHARSET が utf8, utf8mb4 以外 (wp-config.php で定義) DB_CHARSET の値 DB_CHARSET が utf8, utf8mb4 かつ utf8mb4 が使える環境 (※1) utf8mb4 DB_CHARSET が utf8, utf8mb4 かつ utf8mb4 が使えない環境 utf8 ※1 「utf8mb4 が使える」 = MySQL 5.5.3 以上 (+ libmysql 5.5.3 以上, mysqlnd 5.0.9 以上) 照合順序 DB_
MySQL 8.0.17現在、PRIMARY KEYやUNIQUE KEYのCOLLATEを変更しても何故か再起動まで反映されない ⇒ 8.0.20で直るらしい 8.0.20で直る、とバグレポートに書いてありますね。 ユニークキー、PRIMARY KEYが文字列型の場合に良くないことが起こる。 このバグが直るまでのバージョンで、「作り間違っちゃった」「あとからやっぱり変更したい」みたいなケースは十分気を付けた方が良いかと… まずは何も考えずに val varchar(32) にユニークキーを作る。 この時の collation_server はデフォルトの utf8mb4_0900_ai_ci のままで、「おっとこれって kamipoのハハパパ問題 が起こるやつじゃん、そういえばデフォルト変わったんだっけ」なイメージ。 mysql80 10> SELECT @@collation_serv
26. EXPLAIN mysql> EXPLAIN SELECT * FROM table_1 a JOIN `table_2` s ON a.user_id=s.`user_id` AND s.site_i d=120 WHERE app_id=8250G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: a type: ref possible_keys: PRIMARY,ix_table_1,ix2_table_2,ix3_table_1,idx_table_1_06,idx_table_1_07,idx_t able_1_09 key: idx_table_1_06 key_len: 4 ref: const rows: 13496 Ext
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
長くアプリケーションをメンテナンスしているうちに、データベースを別の環境に移行する機会もあるかと思います。私が経験したPostgreSQLからMySQLへの移行における手順を示しておきます。 このシステムは下記のような特徴を持っているため、かなり簡単な部類に入るかと思います。 データをバッチで突っ込む以外に更新は無い TRIGGERは使わない VIEWは使わない それらしい機能は全然使わない 機能も大したこと無い、それゆえに制限も無いということで、データベース・エンジンはMyISAMにしました。テーブルの関連付けは移行しないということです。関連付けも移行する場合はまた別途手順が必要になるでしょう。 PostgreSQLのデータをエクスポートする PostgreSQLの付属のプログラムpg_dumpを使います。ここでは、ダンプするデータベースの名前をdb1としておきます。この時、後の作業のた
レポジトリが https://github.com/perl5-dbi/DBD-mysql ここに変わっていた。 https://github.com/CaptTofu/DBD-mysql/issues/51 この issue は buffer overflow なので、ちょっとまあアレなんだけど2年前から放置されてて困ったなーと思っていたが、なんか新体制で別のレポジトリで解消されていた。 具体的には以下のようなコードで、バッファオーバーフロー発生していた。sprintf でエラーメッセージを生成している部分で、固定バッファ使ってるというわりとよくあるISSUE。 perl -MDBI -e 'DBI->connect("dbi:mysql:dbname=test", "root")->prepare("?")->bind_param(1, "2014-01-01 00:00", 4)'
アプリをリリースできる状態に保ったまま 段階的にリファクタリングするための 戦略と戦術 / Strategies and tactics for incremental refactoring
ども、cloudpack の 自称インフラエンジニアかっぱ (@inokara) です。 インフラエンジニアに定年は無い ので MySQL の join 位は挙動を抑えておきたいのでどさくさ紛れに動作確認を行ったのでその際のメモ。レプリケーションが狂ってしまった!等の時にマスターとスレーブの差分をチェックしなければいけないって状況になった時に役立ちそうな気がするけど…そんな事も知らんのかって怒られそうで怖い。 あと、mysqldiff という Perl 製のツールが紹介されていたので試してみる。 参考 mysqldiff DBテーブルの差分を出力するMySQL::diffをインストールする メモ 動作確認準備 create database d1; use d1; create table t1(id int, user_id varchar(20)); create database d
この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの
若干それますが、あまりに対応するのもどうかと思いますが、ディレクターや顧客が「あのデータ手が滑って削除にしちゃったんだけど、やっぱり戻せない??」っていうのを無視するのはどうかと思いますし、開発時とか運用当初はいまいち要件も定まっていないことが多いはずなので、そういう観点からもしっかりそのほかの手法も組み合わせるべきですよね? 実際の組み合わせ 運用状況に応じて以下のように組み合わせるのが一般的ではないでしょうか? [Web型]mysqldump系 + bin-log + レプリケーション [Web型]mysqldump系 + レプリケーション [どうでもいい系,α版]mysqldump系 + bin-log [バッチシステム]mysqldump系 バッチの場合は楽ですね。で、今回はたいしてお金ないんだけど、まぁしっかりバックアップっぽいことをやりたいケースへの対応として最低限の「mysq
全てのスレーブに固有のサーバIDを割り当てないといけない。 一つのスレーブにはマスターを一つだけ割り当てることができる。 一つのマスターに多数のスレーブを割り当てることができる。 スレーブはほかのスレーブのマスターになることができる。 がある。 だが、最初の規則は必ずしも正しいわけではない。 ■ レプリケーションの構成について 先ほどの規則に基づいて簡単なレプリケーションを構成例を挙げる。 ■ 1つのマスターと複数のスレーブ 最も基本的なレプリケーション。 この構成が有効なのは、書き込みが少なくて読み出しが多い場合。 問題点としてはマスターからスレーブへの帯域幅である。
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のときのデフォルト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く