Describes how to write a MySQL storage engine - a plugin which is responsible for persisting MySQL table data. Download source code - 1.6 MB Introduction This article summarizes the things that I learned when I wrote a new MySQL storage engine (“SE”). MySQL’s storage engines are plugins which are responsible for actually storing the data on disk, and providing access to the data. The SEs usually a
このエントリーは Classi developers Advent Calendar 2022の18日目。 ネタはなんでもいいよ！とのことなので、Claasiに全く関係なく、MysqlからPostgreSQLに移行する際の注意点を書く。 なお、まだRDSにPostgreSQLがなかった頃のような昔の記事だがこちらに無いことを書いていく。 soudai1025.blogspot.com soudai1025.blogspot.com MySQL から PostgreSQLにデータ移行する際の注意点 MySQLとPostgreSQLは互換性がもちろんありませんので、細かいところで違いが発生します。 よく踏むデータ移行の注意点は以下の通り。 timestampやdatetimeを移行する先はtimestamp型になるが、timestamp型はタイムゾーン付きと無しがある timestamp wi
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
はじめに Djangoを使ったアプリケーションで、2つのバッチ処理用プロセスA、Bを同時に立ち上げたときに、Aのトランザクションでsave & commitした値をBでは読み取れないという問題に直面しました。 問題の箇所のソースコードはこのような感じです。 実行順 プロセスA プロセスB 1 with commit_on_success(): p = Post(id=1) p.save() 2 # saveしたデータが見える Post.objects.get(id=1) 3 with commit_on_success(): p = Post(id=2) p.save() 4 # saveしたデータが見えず例外発生 Post.objects.get(id=2) Djangoではデフォルトで自動コミットが有効なので、Aでコミットした値をBで読み取れるはずと思っていたのですが、これは間違いでし
Lost connection to MySQL server during query MySQL でクエリを発行した際に、Lost connection to MySQL server during queryというエラーメッセージが出ることがあります。これは事実を表しただけのメッセージであり、どうすればエラーが出なくなるのかがわかりづらいために困ります。 おそらくアンチパターンに近い解決法 いろいろ調べたところ、MySQL のタイムアウトの値に問題がありそうということが分かりました。そこでまずは現在の設定を見てみます。 mysql > SHOW VARIABLES LIKE '%timeout%'; +-----------------------------+----------+ | Variable_name | Value | +-----------------------
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
MySQLにおけるレプリケーション遅延の傾向と対策
レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ
REPLACE文について unknown REPLACE文は、INSERT文とUPDATE文を合体させたようなものです。 挿入するデータが既にテーブルに存在する場合は、新しくレコードを挿入せず、既存のレコードを新しいデータで上書き（置換）します。（UPDATE文と同じ） 逆に、挿入するデータがテーブルに存在しない場合は、新規レコードを挿入します（INSERT文と同じ）。 またREPLACE文は、INSERT文同様、SELECT文の結果を挿入することが可能です。 INSERT INTO テーブル名(フィールド名) VALUES (値) SELECT 文; REPLACE INTO テーブル名(フィールド名) VALUES (値) SELECT 文; # MySQLログイン、データベース選択 C:\mysql\bin> mysql -u root -p db_User Enter Enter
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
31. レプリケーションスレーブに注意 (FIXED by 5.7.9) REPLICATION SLAVE権限の *他に* SELECT ON performance̲schema.* が必要 mysql> show slave statusG *************************** 1. row *************************** .. Last_IO_Errno: 1142 Last_IO_Error: The slave I/O thread stops becaus e a fatal error is encountered when it try to get the value of SE RVER_ID variable from master. Error: SELECT command denied to use r 'replic
概要 MySQLのメモリ関係のシステム変数について、まとめてみました。 構成 MySQL Ver 14.14 Distrib 5.5.14, for Linux (x86_64) using EditLine wrapper メモリサイズの見積もり はじめに、MySQLのプロセスが必要とするメモリサイズの見積もり方法を確認します。 必要なメモリサイズ ＝ グローバルバッファのサイズ ＋（スレッドバッファのサイズ × 最大同時接続数）グローバルバッファのサイズは以下の方法で計算します。 max_heap_table_sizeは必ずしも割り当てられる訳ではありませんが、安全側に倒すため、計算に含めています。 グローバルバッファのサイズ ＝ key_buffer_size ＋ innodb_buffer_pool_size ＋ innodb_additional_mem_pool_size ＋
MySQL-Python (MySQLdb) のメンテナンスが停滞したことで fork して後方互換性を保ったままメンテナンスをしている mysqlclient ですが、 Django の recommend になりました。 Databases | Django documentation | Django もともと推奨になっていた MySQLdb が Python 3 をサポートしないままメンテナンスが停滞していることが問題になり、対立候補が MySQL Connector/Python と mysqlclient でした。 Oracle 公式の安心感（僕個人が片手間にやってるよりは圧倒的に開発リソースを避けるはず）も捨てがたいのですが、クエリ結果のカラム数×行数（＝MySQLパケット数）が多い時に Pure Python の MySQL Connector/Python と libmy
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
