MySQLがバージョン5から8に飛んだ謎、意外と知らないCharset、Collationのこと - Qiita
はじめに 今回はMySQL 8.0について以下の内容を紹介します。 なぜ、バージョン5から8に一気に上がったのか Charsetとは何か Collationとは何か Youtubeでも解説しているので、ぜひ確認してみてください。 【YouTube動画】MySQL8.0 MySQLの名前の由来 MySQLは共同創設者のMichael Widenius (通称 Monty) さんの長女 Myにちなんで名付けられました。 ちなみに、MySQLをベースに、完全なGPLライセンスにしたMariaDBは、次女のMariaにちなんでいます。 [参考] Why is the Software Called MariaDB? MySQLがバージョンアップで5から8に上がった理由 MySQL 6.0はストレージエンジンにFalconを搭載したものを作っていたそうです。 しかし、Falconではなく、InnoD
CREATE TABLE `students` ( `id` int(4) unsigned zerofill NOT NULL AUTO_INCREMENT PRIMARY KEY, `name` varchar(255) NOT NULL, `gender` varchar(1) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; INSERT INTO `students` (`id`, `name`, `gender`) VALUES (0001, '長岡 一馬', '男'), (0002, '中本 知佳', '女'), (0003, '松本 義文', '男'), (0004, '佐竹 友香', '女'); CREATE TABLE `exam_results` ( `studen
Amazon Aurora DB のプロダクションクラスターを実行しています。リーダーインスタンスが「リードレプリカがマスターに対して相当な遅れを取っています。MySQL を再起動しています」または「リードレプリカがマスターに対して相当な遅れを取っています。postgres を再起動しています」というエラーで再起動されました。 簡単な説明 AuroraReplicaLag は、Aurora DB クラスター内のライター Aurora DB インスタンスからリーダーインスタンスに変更をレプリケーションする際の遅延をミリ秒単位で測定したものです。Aurora レプリカは、ライターインスタンスと同じストレージボリュームに接続します。ライターインスタンスとリーダーインスタンスの間の遅延を測定するには、Amazon CloudWatch の AuroraReplicaLag メトリクスを使用します。
独自テーマの有効化の際に専用テーブルをデータベースに追加する必要がありましたので、先日追加したテーマ有効化時に実行されるアクションフックポイントに追加するテーブル作成用の関数を追加しました。 独自テーブル作成 以下のテーブル作成用関数を functions.php などに追加します。 /** * お気に入り用テーブル作成 */ function ag_create_table_favorites() { global $wpdb; $table = $wpdb->prefix.'ag_favorites'; //テーブルが存在していなければ作成する if ($wpdb->get_var("SHOW TABLES LIKE '$table'") != $table) { $sql = " CREATE TABLE IF NOT EXISTS `$table` ( `id` bigint(20
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.11.2 オンライン DDL でのパフォーマンスと並列性に関する考慮事項
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
How to create a database table when activating a WordPress theme - Lab21 Web Development Studio
Recently,we came across the need of automatically creating a database table, the first time a WordPress theme is activated. Over at Lab21 we create our own themes for each project. This gives us the power of doing whatever we want, with no limitations. So for this, we have created our own WordPress “naked” theme, pre-stocked with all the functionalities we always use. Having pre-sets in our theme
最終状態がかなり不安定で3回に1回くらいfailしない感じだったのですが、もう安定化を探る時間もなく、時間配分に失敗してしまいました。 ここは司令塔として改善点。 予選じゃなくて本選だしワンチャン賭けようみたいな不慣れなことをしたのがアレだったのかな。。。 無力感ではなく力不足感が強いので、また来年強くなってリベンジしたいです。 いまのところISUCON開始から10年経っても高頻度で上位をウロチョロできているので、引き続き上位を賑やかしていきたい。 そしてワンチャン狙いたい。 ここ2年で「基本的な方法論は引き続き通用するな」というのを確認できたのは収穫です。 今回はfailだったけど、コード読み書きやプロダクト習熟、体調管理みたいな基礎力を上げればスコア的には2～3位が狙える位置にいけそうです。 envoy初めて、WebPush初めて、gRPC初めて、にしてはうまく回せたと思います。 途中
さくらVPSのOSをCentOS 8に、Redmineを4.1に更新 まとまった休みが取れたので、さくらVPSのサーバーのOSをCentOS 7から8に上げて、合わせてRedmineを3.4から4.1に上げる作業を実施しています。更新作業中はRedmineにコンテンツを挙げられないので、はてなに経過をメモすることにします。 CentOS 8への更新 さくらVPSが提供するOSインストール機能で、CentOS 8に上げます。さくらVPSサーバのバージョンはv3なので、標準OSのインストールではCentOS 8は選べません。カスタムOSのインストールでCentOS 8を入れます。 パーティションの設定 仮想ゲストでディスク（イメージファイル）を増やすこともないので、LVMは使用せず、/boot はext4、/はxfs、それとswapの3つのパーティションを作成しました。 マウントポイント 容量
OSSデータベース取り取り時報 第84回MySQL 8.0.30がリリース、次のバージョンPostgreSQL 15をベータ版から予習しよう この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。 2015年9月の第1回から連載が始まり、今回で満7年間続けることができました。次号からは8年目に突入します。これからもよろしくお願いいたします。 ［MySQL］2022年7月の主な出来事 2022年7月のMySQLの製品リリースは、MySQLサーバー8.0.30、5.7.39の各マイナーバージョンをはじめ、MySQL NDB Clusterや各種Connector, MySQL Shell, MySQL Workbenchなどのクライアントプログラムの商用版、およびコミュニティ版のほぼ全ての製品のマイナーバージョンアップが行われま
Mroonga(MySQL)やLIKE・FULLTEXTインデックスの全文検索の性能を比較してみた｜SHIFT Group 技術ブログ
はじめにこんにちは、SHIFT の開発部門に所属している Katayama です。 性能比較のためにdocker-composeでMroonga(MySQL)のセットアップをしたら結構時間がかかった話では性能比較のために Mroonga のセットアップをやってみた所、思ったよりも時間がかかってしまった事を取り上げた。 今回はその記事のまとめで触れていた Mroonga を用いた場合の全文検索の性能について、実際に InnoDB との速度を比較してみたのでそれについてみていきたいと思います。 ※「おまけ」では LIKE による検索での速度計測してみたり、転置インデックス・完全転置インデックスでの速度の違いに関しても触れています。 本題の前に 日本語全文検索の速度向上のために取れるアプローチは？実際に全文検索の速度の比較を見ていく前に、全文検索の速度を向上させるためにどのような選択肢があるか？
［速報］オラクル、Azureからも分散インメモリDBのMySQL HeatWaveを利用可能に。「MySQL HeatWave on Azure」発表。Oracle CloudWorld 2022
オラクルは米ラスベガスで開催中のイベント「Oracle CloudWorld 2022」において「MySQL HeatWave on Azure」を発表しました。 MySQL HeatWaveはMySQLに搭載されているInnoDBに加えて分散インメモリデータベースエンジンを搭載。OLTP処理はInnoDBで実行し、OLAP処理は分散インメモリデータベースエンジンで実行することにより、MySQLそのままで統合的にOLTP、OLAP、機械学習処理などを高速に実行するマネージドサービスです。 もともとOracle Cloud Infrastructure上でのみ提供されていましたが、オラクルは先月（2022年9月）、AWS上で稼働する「MySQL HeatWave on AWS」の提供を発表しました。 参考：AWS上で分散インメモリDB「MySQL HeatWave」、オラクルが提供開始。Am
InnoDB におけるページとインデックスの物理的な構成について - それが僕には楽しかったんです。
この記事は「 けんつの１人 DBMS アドベントカレンダー Advent Calendar 2019 - Adventar 」 9日目の記事です。 はじめに 参考にしたサイト InnoDB のスペースファイルレイアウト ページ構成 FIL Header FIL Trailer Header, Trailer の構造的特徴 スペースファイル テーブル毎のスペース おわりに はじめに どうも、最近このアドカレが本当に終わるのかどうなのか心配になってきているけんつです。 今回は DBMS のストレージ構造を考えていたらインデックスを物理的に保存する場合の構造ってどうなってるんだろうなぁと思ったので InnoDB の内部構造とその物理的な形式を追っていく。 あんまり深く追ってしまうと本当にキリが無いので自分の理解が足りない部分をメモしていく感じになる 参考にしたサイト blog.jcole.us
MySQL/Aurora/TiDBロック入門 – 第７回ギャップロックと消えるロック【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第７回ギャップロックと消えるロック【解説動画付】 MySQL のロックについて解説する入門シリーズの第７回です。今回は挿入を止める以外に排他や共有のロックの機能もあると錯覚してしまいがちなギャップロックと INSERT に関するロック動作について解説します！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回ギャップロックと消えるロック ★ 第８回 ネクストキーロックと降順インデックス ★ 第９回 共有ロックで発生しやすいデッドロック ★ 第１０回 ロック読み取りが READ COMMITTED
「Developers Summit 2024」では、「マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB」と題し、イオンスマートテクノロジーがマイクロサービスアーキテクチャを採用した際に発生している課題解決にどう取り組んでいるかの紹介がされた。マイクロアーキテクチャを採用したことで発生するトランザクション管理の難しさや、新たに必要となる組織設計などの課題に対し、TiDBの水平方向のスケーラビリティ、強力な一貫性、高可用性、HTAPなどの特長が有用と考えている。講演では同社がTiDBの導入を検討する背景、TiDB Cloud導入によりどのような変化があると予測しているかなどを、イオンスマートテクノロジー株式会社 CTO室SREチームリーダーの香西俊幸氏が解説した。 イオンスマートテクノロジーが期待するTiDBとは 2020年10月に設立されたイオンスマートテク
MySQLのJSONの活用方法に関して説明をしてきましたが、第205回 MySQLでJSONを活用してみる［その4］でMySQL 8.0.17から導入された複数値indexを活用してもっと便利に扱う方法を紹介しました。 今回は、複数値indexを実際に運用する際に注意しなければならない点を紹介していきたいと思います。 検証環境 今回は、Dockerで建てたMySQLを使用します。以下のコマンドでDockerを建ててローカルからアクセスをします。 % docker run --platform linux/x86_64 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest アクセス方法は以下の通りになります。 % mysql -uroot -pmy-secret-pw -h127.0.0.1 -P3307 執筆時点で
MySQL:移行手順(5.7 → 8.0)
virtualboxにてMySQL5.7 → 8.0の移行を行った。 手順の整理、影響の洗い出しを目的とするため、mysqlの設定(my.cnf)については最低限のものとした。 MySQL 5.7 構築 OS環境 [root@node3 ~]# uname -a Linux node3 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [root@node3 ~]# # リポジトリ追加 [root@node3 ~]# yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm # 登録されている全てのリポジトリを表示 [root@node3 ~]# y
gtid_mode=OFFの移行元MySQLからGroupReplicationにマイグレーションするはなし
origin側はgtid_mode=OFF, binlog_format=MIXEDでこれを変えてはいけない MySQLはこのケースに限り 8.0.28 以外でも良い メンテナンスには入れられる。ただし、メンテナンスウィンドウ内でMyDumperをかけられるほどデータは小さくない なおGroupReplication ≠ InnoDB Clusterとした。つまりMySQL Shellの支援とMySQL Routerプロセスは使わない シングルプライマリーモード。MySQL Routerは使わないけど到達性の問題は 俺以外の誰か が何とかするものとする（実際、何とかしてくれた） まずはフツーに空っぽの状態でGroupReplicationを組む。 これはほぼGetting Startedの通りにいった気がする(3か月くらい前なので既にやや記憶が曖昧) MySQL :: MySQL 8.0
第129回 Internal Temporary Table（内部テンポラリテーブル）について［その1］ では内部テンポラリーテーブルを使用するステートメントやその確認方法、またMySQLの各バージョンでの内部テンポラリテーブルの違いについて紹介しました。 今回はその続きで、主にMySQL 8.0で追加された内部テンポラリテーブル用のストレージエンジン、TempTableストレージエンジンについて紹介したいと思います。 今回も前回同様MySQL 8.0.21を基にして紹介します。 TempTableストレージエンジン MySQL 8.0は、デフォルトでインメモリテンポラリテーブルとディスクテンポラリテーブルがTempTableとなっています。 TempTableストレージエンジンの特徴として以下があります。 可変長データ型の効率的なストレージの提供 バイナリラージオブジェクト型のサポート
isucon10.md
isucon10.md 再起動試験で落ちていた件の調査 - NaruseJun 理由 apparmorのポリシー(mysql-serverパッケージに入ってる/etc/apparmor.d/usr.sbin.mysqld)が生きていて、systemdがmariadbの起動を検知できておらず、systemctl stop相当の処理がかかったため。 疑問1: mariadbに入れ替えたときにto-hutohuがaa-remove-unknownでポリシーを消したのでは？ これはそもそも恒久対応ではなかった。 /etc/apparmor.d/usr.sbin.mysqldはmariadbインストール時に空になっている。 が、リブート時にはmysql-serverパッケージ由来のapparmorポリシーが適用されているという経験があった Ubuntuでmysql-serverをmariadb-se
MySQL で一意制約が削除できない
基本: 外部キーに使われているインデックスは削除出来ない MySQL でインデックスを削除するときに、以下のようなエラーメッセージが出る事があります。 普通に読めば、そのインデックスが外部キーによって使用されているので削除出来ない、という話です。解決方法としては インデックスはそのまま残す外部キーを削除してからインデックスを削除する といったところだと思います。 ここまでは当たり前の話なのですが、なぜこう言う状態になるのか分かりにくいケースがあったので、説明します。 分かりにくいケース 実例: 後から一意制約を追加した場合 以下の通りテーブルを2つ作成します。 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
MySQL闇歴史2 Embedded InnoDB 本エントリはMySQL闇歴史 Advent Calendar 2022 の2枚目のカレンダー9日目のエントリーです。 梶山さんが以下のエントリで触れているようにInnoDBには組み込みInnoDB(Embedded InnoDB)というものが一瞬ありました。 MySQL闇歴史 Innobase Oy ニュースにもなりましたし、Web Archiveをたぐってみるとバージョン1.0.6までリリースされました。 が、しかし、継続はされず、こっそりとフェードアウトしました。 何が悪かったかというと、やはり「組み込み(Embedded)」という名前で多くの人が想像するものと、 実際にリリースされたものに大きな乖離があったからではないかと類推します。 通常組み込みというと、以下のような三つのプロファイルがあり、用途に応じて構成変更して利用するのが一
The Aurora MySQL replication features are key to the high availability and performance of your cluster. Aurora makes it easy to create or resize clusters with up to 15 Aurora Replicas. All the replicas work from the same underlying data. If some database instances go offline, others remain available to continue processing queries or to take over as the writer if needed. Aurora automatically spread
ridgepole 導入はまりどころ - Qiita
超高速チーム開発中、なのだが、 - DBスキーマの変更が多発 - migration重なりすぎて、最終形が追えない - 仕様との突合つらい ということで、ridgepoleに移行中です。 GWって、ちょうどよいですよね。 だいぶいい形になりそうです。 実運用までには、まだまだ宿題多数。 その過程でのはまりどころ + 残課題をここで整理して潰しこんでいきます。 導入方法は他のいい感じのページにお任せします 例 - 本家 - さらばmigration よろしくridgepole dotenv 付きの config/database.yml と相性が悪い 本PRJでは、config/database.ymlにdotenvを使用しています。 で、ridgepoleをconfig/database.ymlを元に実行しようとすると、 だいぶ不親切なエラー しかも、エラーが浅いのよね。 verboseに
この記事は「けんつの１人 DBMS アドベントカレンダー Advent Calendar 2019 - Adventar」 15 日目の記事です。 はじめに B Tree を実装する インデックスの色々 クラスタインデックス セカンダリインデックス B Tree アルゴリズム 実装方針 実装するにあたっての知見・感想 アイテムの閾値 ラッチの実装 Golang の interface を上手く使う B Tree の実装 終わりに はじめに どうも、最近眼精疲労がひどすぎるけど眼球ってどうやって休めたらいいかわからないけんつです。 今日明日は現状最も苦戦した B Tree Index と Buffer Pool の実装話になります。 B Tree を実装する 今回は B+ Tree でなく B Tree を実装する。また削除は考慮しない。 完全に考慮しない訳ではなくて一応削除を実装することを
CLIでTypeORMのプロジェクトを構築して、TypeORMの大まかな利用方法を確認します。「migrationの実行」「CRUDの動作確認」など行います。 CLIで新規プロジェクト構築 プロジェクト構築 ( typeorm init ) 新規プロジェクト用のフォルダを作成します。 $ mkdir sample_init $ cd sample_init TypeORMの CLI でプロジェクトを構築します。今回、DBは MySQL を利用します。 $ npx typeorm init --database mysql Project created inside current directory. フォルダ確認 CLI で生成されたファイルを確認します。 $ tree . ├── README.md ├── ormconfig.json ├── package.json ├── sr
MySQLのLIMIT句の入れ子による面白い挙動と将来リリースでの修正予定 - sakaikの日々雑感～(T)編
とみたさんから、MySQLの次の次のバージョンで挙動が変更になる話を教えてもらったので、記録。 mysql> use mysql mysql> SELECT user FROM user LIMIT 2; +------------------+ | user | +------------------+ | mysql.infoschema | | mysql.session | +------------------+ 2 rows in set (0.00 sec) 適当なテーブルから LIMIT句を使って2件のデータを取得したもの。これはまぁ普通の挙動。 次に、これを入れ子にしてみる。 mysql> (SELECT user FROM user LIMIT 2) LIMIT 3; +------------------+ | user | +------------------+
負荷試験＃検証と最終診断 | 外道父の匠
負荷試験＃採取と整理 の続きを１年越しに再開です。 今回は負荷試験の結果を見て、何をどう判断して進めていけば良いのか、どのような判断事例があるのかという話です。 正常系と異常系の結果 負荷試験の大きな目的の１つである【スループットはどの程度を出せるのか】を判断するには、あえて異常な状態までトラフィックを流し込む必要もあります。 スループットに対するグラフの特徴としては、キレイな正常系と途中から不安定になる異常系があるとして、Locustでグラフの例を示してみます。 正常系 この例はユーザーを 30万 まで 500spawn/s で徐々に増やし、12000 RPS まで流し込んだグラフです。 エラーはゼロで、レスポンス速度もユーザー生成完了後は 50%tile で 70ms弱 と、良好な結果となっています。 嬉しい結果ではありますが、負荷試験の診断という意味ではこれだけでは不足です。正常な結
本記事は東京学芸大学 櫨山研究室 Advent Calendar 2020の九日目の記事になります． はじめに 今回はMySQLを使った全文検索について扱いたいと思います． MySQLでは5.7よりInnoDBを使って簡単に全文検索を実現することができます． 本記事はMySQLのN-gramパーサーを使って日本語の全文検索を実現する方法を取り扱います． N-gramとは？ まずN-gramについて簡単におさらいをしておきます． N-gramとは任意の文字列をN文字で区切った形で表す方法です． 例えば自然言語処理という文字列をN=2のN-gramで表現する場合 という形になります． N=1の場合をunigram，N=2の場合をbigram，N=3の場合をtrigramと呼びます． なおMySQLのN-gramパーサーはデフォルトでbigramを使用します． MySQLの準備 MySQLサーバ
前提 Pythonのmysql.connectorには、 self.conn.commit() self.conn.rollback() 上記の、トランザクションのコミットもしくはロールバックのメソッドは存在します。 しかし、トランザクションの「開始」用のメソッドは存在しません。 存在しませんが、自動でトランザクションを開始してくれているわけではないので、自前で トランザクションを開始させる必要があります。 実現方法 mysql.connector.cmd_query('START TRANSACTION') これを起動することでOKです。(MySQL用のトランザクション開始クエリーをself.conn.cmd_query メソッドで発行します) おまけ mysql.connector.cmd_queryは引数に指定した文字列のクエリを発行してくれるため便利です。 mysql.connec
goを使ってGormを使ってデータベース操作する必要が出てきたのでいろいろ調べた結果をまとめます。 データベーススキーマの作成 まずはスキーマの作成の仕方についてみていきます。 Migrate Migrateは、接続先のスキーマを参照して、テーブルやカラムがなければ自動的に作ってくれるコマンドです。 足りない関連やテーブルを自動で作ったりはしてくれるが、勝手にカラムを消したりすることはしないとのこと。 Auto Migration Automatically migrate your schema, to keep your schema up to date. NOTE: AutoMigrate will create tables, missing foreign keys, constraints, columns and indexes. > > It will change ex
Adventarを支える技術 Advent Calendar 2019 の15日目です。 今日は DB のスキーマ管理について書きます。 Rails の DB マイグレーションと Ridgepole Adventar は昨年まで Rails で作っていて、DB の マイグレーションも Rails デフォルトの機能を使っていました。Rails の DB マイグレーションは、それなりによくできてはいますが、差分を積み上げていくので大量のマイグレーションファイルができて煩雑になる、多人数での開発の場合にコンフリクトしやすいなど、いくつか問題があります。 個人的にはこういった問題もあるので、Ridgepole のように DB のスキーマ定義だけを管理し、現在のスキーマとの差分を計算して ALTER 文を発行してくれるような仕組みのほうが好きです。 最初は Ridgepole を使おうと思ったのです
こんにちわ。せじまです。 今回も replication の話をします。 はじめに 第四回です。 前回、 Row-Based Replication では Column の名前を意識していないことを確認しました。今回は Row-Based Replication で online schema change できないか、そのへん試してみましょう。 まずは厳重注意 これから記述する内容を本番環境で実施する場合、リスクをともないます。まずは検証環境で試しましょう。 いちおうまとめ master の方が Column が少なかった場合、 slave にしか存在していない Column の振る舞いは、 Worklog 5092 で規定されているようなものでした。デフォルトの値で更新されます。 よって、 slave でtableの末尾に add column する程度なら動く気がします。公式ドキュメ
バルクインサートと比較すると要件が複雑なため、バルクアップデートの実現方法はいくつかあります。 この記事では3つの方法に対して実行速度の違いを比較します。 UPDATE ~ ELT + FIELD UPDATE ~ CASE INSERT ~ ON DUPLICATE KEY UPDATE 要件によっては上記以外の方法でも十分なケースもあるため、以下の条件を設定しています。 レコード毎に違う内容で更新 更新前の値を使用 特定のカラムのみを更新し、他のカラムは変更しない 実際にありそうなケースとしては、ユーザごとにポイントを保持するテーブルがあり定期的に集計処理を走らせてその内容に応じてポイントを加算するようなのを想定してます。 使用するテーブル CREATE TABLE `users` ( `user_id` int(11) NOT NULL AUTO_INCREMENT, `field1
MySQL Performance Optimization with Percona Monitoring and Management - Webinar Followup
Last week I did a webinar on MySQL Troubleshooting and Performance Optimization with Percona Monitoring And Management v2 (PMM2). There was a tremendous amount of interest and many more questions than I could answer, so I’m answering them in this blog post instead. Q: What are the red and white dots on the last column in PMM Query Analytics? This is a graphical visualization of the query response
EC-CUBE4カスタマイズ - セッションをファイルではなくデータベースに保存する方法 PdoSessionHandler
EC-CUBEでロードバランサーを使ったウェブサーバー冗長化には必要になってくる、セッションの脱ファイル化、DB化についてご紹介します。 EC-CUBE4では簡単な３ステップでセッションのテーブル保存を実現することができます。 1. セッションを保存するテーブル作成 マイグレーションなどでセッションデータを保存するテーブルを作っておきます。BLOBだと足りないことがあるのでLONGBLOBにしておくのがポイントです。ちなみにMySQLです。 public function up(Schema $schema) : void { $this->addSql('CREATE TABLE `sessions` ( `sess_id` VARCHAR(128) NOT NULL PRIMARY KEY, `sess_data` LONGBLOB NOT NULL, `sess_time` INTE
Brought to you by Rick James The Problem You have a SELECT and you want to build the best INDEX for it. This blog is a "cookbook" on how to do that task. ⚈ A short algorithm that works for many simpler SELECTs and helps in complex queries. ⚈ Examples of the algorithm, plus digressions into exceptions and variants. ⚈ Finally a long list of "other cases". The hope is that a newbie can quickly get
RDS インスタンスのステータスが「incompatible-parameters」になった際の調査方法 | DevelopersIO
はじめに DB インスタンスの メモリ不足 によってincompatible-parameters が発生している場合がございましたので、調査方法をご紹介します。 困っていた内容 RDS インスタンスのステータスが incompatible-parameters となっているが、 AWS のナレッジセンターに記載の解決方法ではステータスが元に戻らない。 ※ パラメータグループのパラメータ値を、エンジンバージョンやインスタンスクラスと互換性のあるものにリセットすることが解決方法として記載されている。 Amazon RDS インスタンスのステータスが、incompatible-parameters になったまま変化しません。どうすれば修正できますか? 調査方法 1. DB接続が可能な状態であるかを確認する アプリからの接続に問題がないか、または CloudWatchメトリクス Database
はじめに 今回は、Spring BootアプリケーションのセッションをDBで管理する方法を調べたので備忘録として書いていきます。 書いてある内容は手を動かして確認したものですが、正しい情報は公式ドキュメント(以下は2.4.3のもの)の内容を見てください。 Spring Session - Spring Boot 環境 Spring Boot 2.4.5 Maven 3.6.3 Kotlin 1.3.72-release-468 Docker version 20.10.8, build 3967b7d MySQL 5.7 spring-session-jdbcの依存を追加 Spring Session JDBC を利用するため、pom.xmlにspring-session-jdbcを追加します。 Spring Session JDBCは、RDBを使ったSessionRepositoryの実
Let’s examine COMMIT latency on Aurora v2 (MySQL 5.7) vs. Aurora v3 (MySQL 8.0) vs. RDS MySQL 8.0 2-AZ vs. RDS MySQL 8.0 3-AZ “cluster”. Why COMMIT Latency? COMMIT is when MySQL incurs storage latency to make data changes durable. Before that, reads and writes are ideally (but not always) in-memory operations. Therefore, CPU and memory (and a few other concerns) affect query response time before C
InnoDB, fsync and fdatasync - reducing commit latency
InnoDB, fsync and fdatasync - reducing commit latency MySQL has an commit penalty compared to Postgres and MongoDB. If you want commit to be durable with the binlog enabled then MySQL does two fsyncs per commit -- one for the binlog, one for the InnoDB redo log. But Postgres and MongoDB only need one fsync per commit in the same setup. Note that I am ignoring the benefit of group commit for now, a
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQL初心者〜中級者のための練習問題&解答例1 - Qiita
Amazon Aurora リードレプリカの再起動に関するトラブルシューティング
WordPress テーマ有効化時に独自テーブルを追加する方法
チーム「ウー馬場ーイーツ」でISUCON10本選で一時トップに立つもfailフィニッシュになりました #isucon
さくらVPSのOSをCentOS 8に更新、さらにRedmineを4.1に更新 - torutkのブログ
第84回 MySQL 8.0.30がリリース、次のバージョンPostgreSQL 15をベータ版から予習しよう | gihyo.jp
ゼロからマイクロサービスに取り組むイオン、DB運用や組織課題の解決に「TiDB」が寄与できることとは
第208回 MySQL複数値indexの制限に関しての補足 | gihyo.jp
第132回 Internal Temporary Table（内部テンポラリテーブル）について［その2］ | gihyo.jp
MySQL闇歴史2 Embedded InnoDB | キムラデービーブログ
Replication with Amazon Aurora MySQL - Amazon Aurora
B Tree Index を実装する - それが僕には楽しかったんです。
TypeORM｜【入門】CLIでプロジェクト構築して使い方を確認 - わくわくBank
MySQLでの全文検索(N-gram編) - Qiita
Python用のMySQLコネクタでトランザクションの開始終了を実装する方法 - Qiita
Gormの使い方についてまとめてみた - Qiita
schemalex による DB のスキーマ管理 - hokaccha memo
チョットワカル Row-Based Replication・その４ | GREE Engineering
MySQLでのバルクアップデートの性能比較 - Qiita
MySQL: Building the best INDEX for a given SELECT
Spring BootアプリケーションのセッションをDBで管理する - daisuzz.log
COMMIT Latency: Aurora vs. RDS MySQL 8.0