PostgreSQL15の最新機能を解説してみる
スターフェスティバル株式会社 の バックエンドエンジニアの @ikkitang です。 上記の自己紹介にもありますが、私はプライベートで日本PostgreSQLユーザー会の理事をやっていて、その活動の一貫として先日の 2022-10-01（土)に行われたOpen Source Conference 2022 Online/Hiroshimaで最新バージョンのPostgreSQL15の最新機能について発表してきました。 スライドは公開しておりますので、以下を見て頂く事で全てを完全に理解していただけるかもしれませんが、解説しながらまとめたいと思います。 PostgreSQLのリリースサイクル PostgreSQLはPostgreSQL開発コミュニティというユーザーグループ主導で開発されています。 毎年9~10月にメジャーバージョンをリリースしておりまして、今年はPostgreSQL15のリリー
UTF-8のテーブル(MySQL5.6)に竈門禰󠄀豆子が格納できない問題を調べてみた - Qiita
竈門禰󠄀豆子を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
MySQL で使用するメモリサイズの見積もり - 元RX-7乗りの適当な日々
最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ
MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア - Cybozu Inside Out | サイボウズエンジニアのブログ
サイボウズの Kubernetes 基盤を開発している Neco プロジェクトの ymmt です。 サイボウズ製品のほとんどはデータベースとして MySQL を採用しています。 現在 400 を越える MySQL のインスタンスを運用しており、これら全てを新しい Kubernetes 基盤に移行していく予定です。 Kubernetes 上でアプリケーションやミドルウェアの運用を自動化するソフトウェアのことをオペレーターと言います。 大量の MySQL インスタンスを Kubernetes 基盤に移行するにはオペレーターが必須であると考え、技術顧問の @yoku0825 さんの監修の下で MOCO というソフトウェアを開発しオープンソースライセンスで公開しました。 本記事では Kubernetes 上の MySQL オペレーターの状況と、開発した MOCO の機能を詳細に解説いたします。 M
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは 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
MySQLとインデックスと私
2021/05/24 サイボウズ開運研修 動画が以下のサイトからリンクされています - https://blog.cybozu.io/entry/2021/07/20/100000 - これに矢印を書きながらぐりぐりやっていたわけなので、資料単体だとわかりづらいと思います…
実例で学ぶ MySQL/MariaDB デバッグ - nayuta-yanagisawa's blog
この記事では、MySQL/MariaDB のバグを修正するための典型的な手順を、具体例を通して解説する。次の MariaDB のバグを例として取り上げるが、基本的なデバッグの手順は MySQL でもまったく同様である。 MDEV-24868: Server crashes in optimize_schema_tables_memory_usage after select from information_schema.innodb_sys_columns なお、MySQL/MariaDB のデバッグ方法についての包括的な解説を与えるのは、この記事のスコープ外である。デバッグ手法の詳細を知りたい場合は、以下の一連の記事を参照してほしい。 Debugging MySQL/MariaDB (1): Build and Test Debugging MySQL/MariaDB (2): DBU
MariaDB 10.5 の性能は不正？
普段は基本的にMariaDBの動向は全く追って無いです。 でも先日、MariaDB 10.5 のfsync()発行が少なく性能が良いのは何故なのかちょっと見てほしいと言われて、 mariadb-10.5.9.tar.gz をざっと見たらあっという間に原因特定。 「fsync()を待つべきなのに待ってないから」 只の不正と判明。 動作としては、 innodb_flush_log_at_trx_commit = 1 でも innodb_flush_log_at_trx_commit = 2 でも 並列度が上がると多くのトランザクションが innodb_flush_log_at_trx_commit = 0 の動作と同等となってしまうようです。 待たないのだから速いに決まってる。こんな不正なものと比較されるのは腹立たしいです。 指定のLSNまでのwriteやflushを終わらせる log_wri
とあるテーブルの中身を一括更新した話から学ぶPITR - Qiita
この記事は本番環境でやらかしちゃった人のアドベントカレンダー9日目の記事です。 https://qiita.com/advent-calendar/2020/yarakashi-production 去年に引き続き、今年も参加させてもらいました。 ※去年の記事はこちら→ データ移行をしただけなのに…（起こってしまったメール誤配信） 今年のネタも15年くらい前の事で、且つ自分が直接関わった事案ではないのですが、「そういやあの事件、今MySQLだったらどうするかな」と思い書くことにしました。 何があったか もうタイトルで出落ちしていますが本番でUPDATE文を実行する際にWHERE句を付け忘れたという事故です。 当時の状況を整理するとこんな感じだったと思います。 対象サービス： 年商10億円くらいの自社サービス 作業内容： 仮登録されている顧客の情報を指定された情報で更新する 作業環境： DB
MySQL 8.0 vs 外部キー制約 vs ALTER TABLEでメタデータロック待ちになったら疑うこと
TL;DR MySQL 8.0(細かくは8.0.4っぽい)とそれ以降は「外部キー制約を持っているテーブルにSELECTするとそのテーブルの親テーブルにもメタデータロック(MDL)を置くようになった」 MDLであるがゆえに foreign_key_checks をOFFにしようが 無効化はできない MySQL :: WL#6049: Meta-data locking for FOREIGN KEY tables WL#6049 “Meta-data locking for FOREIGN KEY tables” and WL#11059 · mysql/mysql-server@6626f76 これ以降にもいくつかコミットが続いている 論より証拠。 サンプルスキーマはこんなかんじ。 CREATE TABLE `item` ( `item_id` int NOT NULL, `registe
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い | コーソルDatabaseエンジニアのBlog
TOP BLOG 技術ブログバックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い コーソルDatabaseエンジニアのブログ 技術ブログ JPOUGMySQLOracle DatabasePostgreSQL対外講演まとめ 2020.05.07 渡部 亮太 バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い 渡部です。Oracle DatabaseだけではなくMySQLやPostgreSQLを含めた複数のRDBMS製品の使用経験があるエンジニアがとても増えているように感じます。 以前は、エンタープライズIT業界におけるRDBMSといえばOracle Database一択でしたが、オープンソースDBの高機能化・高信頼性化と、ライセンスコスト削減圧力の高まりにより、MySQLやPost
RDBMSのモニタリングについて - そーだいなるらくがき帳
dbstudychugoku.github.io 中身の薄い資料で登壇してきた。 speakerdeck.com 具体的な内容が知りたい人は末尾に関連リンクをまとめたのでそっちを見て欲しい。 資料には書いてないけど伝えたかったことをまとめる。 RDBMSの監視の勘所 RDBMSがどれくらいのトランザクションを捌けるかというのが大切な要素の一つ。 単純な処理が多くてキャパオーバーになったとき、多くの場合はインスタンスのサイズを上げるなどのスケールアップで対応できる。 これは費用対効果の高いケースが多く、有効な手段だ。 しかし ロックが原因の場合 はスケールアップしても問題が解決しないことが多い。 例えばバッチ処理で長時間テーブルロックを取り、それが起因でパフォーマンスが問題になっているときは単純なスケールアップで問題は解決しない。 よく見られる処理例は次のようなケース。 トランザクションを開
長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon RDS移行のための 性能検証でわかった2つのこと