「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 執筆時点で
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弱 と、良好な結果となっています。 嬉しい結果ではありますが、負荷試験の診断という意味ではこれだけでは不足です。正常な結
Google Cloud DMS 利用時のダウンタイムの検証 [DeNA インフラ SRE] | BLOG - DeNA Engineering
はじめに こんにちは。IT 基盤部の岡崎です。 現在 IT 基盤部では、社内利用が多いクラウドサービスについて、ポータビリティの向上を目指す施策を行っています。 具体的には、異なるクラウドベンダ間で同等の機能を持つサービスへ移行する方法を整えることにより、ベンダロックインされない運用を目指しています。 この施策の一環として、いくつかのクラウドサービスを対象に調査を行いました。調査結果は連載形式で順次公開していく予定です。 すでに以下の記事を公開していますので、こちらもぜひ御覧ください！ DB のポータビリティ: Percona XtraBackup: 高性能 DB バックアップツール [DeNA インフラ SRE] GKE のポータビリティ: GKE→EKS のマイグレーションツール ‘KMF’ の検証 [DeNA インフラ SRE] 本記事では、データベースのポータビリティ向上を対象とし
![Google Cloud DMS 利用時のダウンタイムの検証 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2c9efd7e808981c10acf8f8f8f808a51d4208ae/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2024%2F06%2Fpca_portability_gcp_dms%2Fcover.png)
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
前提 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
はじめに Cloud SQLにはEnterprise Plusというエディションがあります。その特徴の1つとして計画メンテナンス時のダウンタイムの短さがあります。本稿ではこのメンテナンス時間の短縮がどのような仕組みで実現されているかを解説します。マニュアルなどではこのメンテナンスの方式のことを「ダウンタイムがほぼゼロの計画的メンテナンス（Near-zero downtime planned maintenance）」と呼んでいます。そのままでは少々長いので本稿では以降、ニアゼロダウンタイムと記載します。 Cloud SQL Enterprise Plusを使うだけであればメンテナンス時の利用できない時間が短いのだなという理解でも十分です。その中で実際に何が行われているか興味がある方のための解説です。 ニアゼロダウンタイムの仕組み詳細 これ以降の説明はCloud SQL Enterprise
試したこと データベースのSQL(DDL)をMermaid形式ER図に変換する Mermaid形式ER図をデータベースのSQL(DDL)をに変換する モチベーション 実際のエンジニアリング作業でよくある問題として、肥大したデータベースをER図に起こして整理したいというニーズはあるかなと思います。 このような問題を解決するツールは世の中にあるりますが、インストールが必要であったり手間がかかることも少なくないと感じます。 例 早速やってみましょう。 例としてブログアプリケーションのデータベースのDDLを使って変換作業をしてみます。 このDDLは、ユーザー、投稿、コメント、カテゴリを管理するためのテーブルを定義しています。ユーザーは複数の投稿を持ち、投稿は複数のコメントを持つことができます。また、投稿は複数のカテゴリに属することができます。 CREATE TABLE `users` ( `id`
STORED はデータ領域とインデックスの両方にデータが保持されるのに対して、VIRTUAL はインデックス側にだけ保持されることになる VIRTUAL は更新時にインデックスのライトコストがかかるものの、インデックスがうまく作用すればリードコストが STORED と同水準になり、さらに空間効率の分有利になる可能性がありそう よって計算式が比較的単純な場合には VIRTUAL はよさそうかも? ところで Secondary Index とは MySQL :: MySQL 8.0 Reference Manual :: 15.6.2.1 Clustered and Secondary Indexes や mysql - How secondary index scan works in InnoDB? - Stack Overflow より Clustered (primary) index
SemisyncレプリケーションのFailoverでなぜデータがずれるのか - tom__bo’s Blog
この記事はMySQL Advent Calendar 2020の1日目の記事です ※ 従来MySQLのレプリケーション構成ではMaster/Slaveという単語が使われてきましたが、現時点の最新バージョンである8.0.22からは、これらの単語がSource/Replicaと置き換えられ始めています。使い慣れた単語を使いたいところですが、ここではMaster->Source, Slave->Replicaという単語に統一します。 cf) https://mysqlhighavailability.com/mysql-terminology-updates/ MySQLのレプリケーション構成には5.7.22バージョンからPaxosをベースとしたGroup Replicationが導入されましたが、運用方法の変化やパフォーマンスなどの理由から従来のレプリケーション方式、特にSemisynchro
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
バルクインサートと比較すると要件が複雑なため、バルクアップデートの実現方法はいくつかあります。 この記事では3つの方法に対して実行速度の違いを比較します。 UPDATE ~ ELT + FIELD UPDATE ~ CASE INSERT ~ ON DUPLICATE KEY UPDATE 要件によっては上記以外の方法でも十分なケースもあるため、以下の条件を設定しています。 レコード毎に違う内容で更新 更新前の値を使用 特定のカラムのみを更新し、他のカラムは変更しない 実際にありそうなケースとしては、ユーザごとにポイントを保持するテーブルがあり定期的に集計処理を走らせてその内容に応じてポイントを加算するようなのを想定してます。 使用するテーブル CREATE TABLE `users` ( `user_id` int(11) NOT NULL AUTO_INCREMENT, `field1
はじめに 今回は、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の実
RDS インスタンスのステータスが「incompatible-parameters」になった際の調査方法 | DevelopersIO
はじめに DB インスタンスの メモリ不足 によってincompatible-parameters が発生している場合がございましたので、調査方法をご紹介します。 困っていた内容 RDS インスタンスのステータスが incompatible-parameters となっているが、 AWS のナレッジセンターに記載の解決方法ではステータスが元に戻らない。 ※ パラメータグループのパラメータ値を、エンジンバージョンやインスタンスクラスと互換性のあるものにリセットすることが解決方法として記載されている。 Amazon RDS インスタンスのステータスが、incompatible-parameters になったまま変化しません。どうすれば修正できますか? 調査方法 1. DB接続が可能な状態であるかを確認する アプリからの接続に問題がないか、または CloudWatchメトリクス Database
innodb_large_prefixが有効になっている時は文字コードをutf8ではなくutf8mb4に設定する必要がある - Qiita
default: &default adapter: mysql2 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password: password timeout: 5000 #下記の2つを追加 encoding: utf8mb4 charset: utf8mb4 なぜ解決できたのか？ 自分でも結果的にたまたま解決しただけではすっきりしないので、なぜ解決できたのか分かる範囲で書いておこう。 以前別のアプリケーションを作った時にMySQLの設置ファイルであるmy.cnfにinnodb_large_prefixを有効にする設定をしていた。 innodb_large_prefixは長い文字列を許可するための設定だ。 今回、encodingとcharsetの設定がそれに合う形に設定されていなかったのが原因だった
【cakephp】RESTapiを作成してjson形式で出力する方法｜InfraAcademy(インフラアカデミー)
今回の記事では、cakephpでRESTapiを作成する方法を解説します。 下記の画像のようにjson形式で結果を出力することができます。 RESTapiが良く分からないという方は、こちらの記事で概要を理解してください。 0からREST APIについて調べてみた – Qiita では、設定方法を解説します。 データの準備まずデータの準備を行います。 データベースにtableを作成して、データーを挿入します。 今回はサンプルとして、usersテーブルを作成しました。下記のSQLを流して作成してください。 -- -- Table structure for table `users` -- CREATE TABLE `users` ( `id` int(11) NOT NULL, `name` varchar(255) NOT NULL, `created_at` datetime NOT N
What is MySQL partitioning? What kind of partition types are there? How do you know if this is something your database engine supports? In this article, we tell you what you need to know about partitioning in MySQL. MySQL partitioning is about altering – ideally, optimizing – the way the database engine physically stores data. It allows you to distribute portions of table data (a.k.a. partitions)
PHPとMySQLを使用し画像ファイルをアップロードし、データベースに保存してみます。また、データベースに保存した画像ファイルをWebページ上で表示させてみます。 ■環境・Windows10 ・Visual Studio Code 1.53.2 ・レンタルサーバー「ヘテムル」 ・FTPクライアント「FileZilla」 ■レンタルサーバーでMySQLデータベースを作成するPHPとMySQLを使用し画像ファイルをアップロードし、データベースに保存を行ってみますが、その前にレンタルサーバーでMySQLデータベースを作成します。今回はレンタルサーバー「ヘテムル」を使用します。 「ヘテムル」のコントロールパネルのログイン（https://admin.heteml.jp/）画面で、「ヘテムルID」と「パスワード」を入力し、「ログイン」ボタンをクリックします。 クリックすると、コントロールパネルの右側
この投稿は 「Django Advent Calendar 2020 - Qiita」 4日目の記事です。 akiyoko です。 この記事では、Django で簡単に楽観的排他制御を実装する方法について説明します。Django の楽観的排他制御については拙著『現場で使える Django REST Framework の教科書』の第11章「現場で使える Tips 集」の中でも触れていますが、もう少し詳しく解説してみたいと思います。 目次 はじめに 楽観的排他制御と悲観的排他制御 READ COMMITTED の挙動 django-concurrency パッケージを利用する まとめ 宣伝 検証環境 Windows 10 Home Django 3.1 PostgreSQL 13.1 はじめに 複数ユーザからほぼ同じタイミングで同じレコードに対して更新をおこなうと、タイミングによってはレース
mysqld/pump、MySQL Shellでもできるって - 三流エンジニアの落書き帳
気づいたら8月でした。（毎回言っている気がする） 今回は小ネタです。 なんか気づいたらMySQL Shellで論理バックアップができるようになったみたいです。 3行で MySQL Shell 8.0.21にutil.dumpSchema(), dumpInstance(), loadDump()なるものが追加された 並列ダンプ(スレッド数の調整)、zstdによる圧縮、進捗の表示など他にも細かい指定ができるみたい 論理バックアップがやりやすくなるかも MySQL Shellによる論理バックアップ MySQL Shell 8.0.21から論理バックアップを取得できる関数が追加されました。 これらの関数は下記のとおりです。 dumpInstance() 接続しているデータベースサーバ全体の論理バックアップを取得する dumpSchemas() 接続しているデータベースサーバの指定したデータベース
はじめに こんにちは、webエンジニアの@an_sonyです。 最近巨大テーブルをalterする機会があり、そのツールとしてpt-online-schema-changeを初めて利用しました。そこで得た知見をまとめてみます。 pt-online-schema-change（以下pt-osc）とは？ 主にMySQL向けに作られた運用ツール群perconaの一つです。 テーブルへのread/writeを許容できる状態に保ったままalter操作を実行することを可能にします。 なぜpt-oscが必要か なにも考えずに通常のalter操作を実行すると、共有ロックを取得するのでinsert/updateができなくなります。alterしようとしているテーブルのレコード数が多い場合、その間書き込みプロセスは待ち状態となり処理が完了しないため、サービスが停止してしまいます。 なお、MySQL5.6からはオン
MySQL、PostgreSQL、SQLite3、SQL Serverのスキーマ定義を宣言的に管理するsqldefを、MySQLで試す - CLOVER🍀
これは、なにをしたくて書いたもの？ sqldefという、MySQL、PostgreSQL、SQLite3、SQL Serverのスキーマ定義をSQLで宣言的に管理できるツールを 知ったので、ちょっと試してみることにしました。 GitHub - k0kubun/sqldef: Idempotent MySQL/PostgreSQL schema management by SQL 今回は、MySQLで試してみます。 sqldef sqldefは、RidgepoleというRuby（Rails）のDSLでスキーマ管理ができるツールにインスパイアされたツールです。 GitHub - ridgepole/ridgepole: Ridgepole is a tool to manage DB schema. It defines DB schema using Rails DSL, and updat
DockerでMariaDB 10.5を使用できるまでの手順をお伝えします。 ここでは、docker-composeとDocker公式のMariaDB 10.5イメージを用います。 ホストOS ホストOSはUbuntu 20.04を用いております。 cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" snapによりインストールしたDockerを用いております。 ただし、sudo権限なしでもdockerコマンドを使用できるようにしております。 docker version Client: Version: 19.03.11 API version: 1.40 Go version: go1.13.
クラウドDB「Oracle MySQL HeatWave」にマシンラーニング機能、SQLを介して学習・推論 | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ データベース ＞ 新製品・サービス ＞ クラウドDB「Oracle MySQL HeatWave」にマシンラーニング機能、SQLを介して学習・推論 データベース データベース記事一覧へ [新製品・サービス] クラウドDB「Oracle MySQL HeatWave」にマシンラーニング機能、SQLを介して学習・推論 結果に影響を与えた列名も説明可能 2022年3月30日(水)日川 佳三（IT Leaders編集部） リスト 米オラクルは2022年3月30日、クラウド型データベース「MySQL HeatWave」の機能拡張について発表した。OLTP（トランザクション処理）とOLAP（データ分析）に加えて、格納データを利用したマシンラーニング（機械学習）機能が備わった。専用のSQL関数をインタフェースとして、学習、推論、根拠の説明（結果に対
Introducing MOCO, a modern MySQL operator on Kubernetes - Kintone Engineering Blog
By Hirotaka Yamamoto (@ymmt2005) We are proud to announce a new MySQL operator named MOCO. MOCO manages MySQL clusters on Kubernetes that replicate data using GTID-based semi-synchronous replication. We will be migrating hundreds of MySQL instances in our production environment to Kubernetes with MOCO. In this article, we describe the current status of existing MySQL operators and why we had to de
Best practices for working with Amazon Aurora Serverless v1 | Amazon Web Services
AWS Database Blog Best practices for working with Amazon Aurora Serverless v1 November 2022: This post was reviewed and updated for accuracy. Amazon Aurora Serverless v1 is an on-demand, auto-scaling configuration for Amazon Aurora. Amazon Aurora Serverless v1 scales instantly from hundreds to hundreds-of-thousands of transactions in a fraction of a second. As it scales, it adjusts capacity in fin
第69回 新しいSQL構文”PLEASE句”の実装!?、MySQL 8.0.24リリース＆マニュアル日本語化、PostgreSQLエンタープライズ・コンソーシアム報告会がまもなく | gihyo.jp
OSSデータベース取り取り時報 第69回新しいSQL構文”PLEASE句”の実装!?、MySQL 8.0.24リリース＆マニュアル日本語化、PostgreSQLエンタープライズ・コンソーシアム報告会がまもなく この連載では、OSSコンソーシアム データベース部会のメンバーが、さまざまなオープンソースデータベースの毎月の出来事をお伝えしています。 新しいSQL構文”PLEASE句”の実装！？ 昨今ポリティカル・コレクトネスが話題となる機会が多いなか、差別的になり得るIT関連の用語の変更が『ニューヨーク・タイムズ』紙でも話題となっていました。この記事の中ではMySQLが例として取り上げられ、20年前にリリースされたMySQL 3.23.15以来使用されてきたレプリケーション関連の用語を2020年に変更したことが紹介されていました。 きっかけは1本のブログ 2021年4月に日本MySQLユーザ会
複数列ソートにおけるカーソルページネーションの実装
こんにちは、@nerusan です。 今回は、複数列ソートにおけるカーソルページネーションについて、説明します。 カーソルページネーションとは？ カーソルページネーションは、データベースのクエリ結果をページごとに取得するための方法です。通常のページネーションでは、ページ番号やオフセットを使用してデータを取得しますが、カーソルページネーションでは、前のページの最後の要素のカーソルを使用して次のページのデータを取得します。 カーソルページネーションの利点は、ページの移動が高速であることです。ページ番号やオフセットを使用する場合、ページ数が増えるにつれてデータベースのクエリが遅くなる可能性がありますが、カーソルページネーションでは常に一定の速度でデータを取得できます。 具体的な実装方法は、データベースの種類や使用するプログラミング言語によって異なりますが、一般的にはクエリパラメータとしてカーソル
次の次のリリースこそは…
Yasufumi Kinoshita 2008年末くらいからInnoDBの改造等で生計を立てていました。2011年末から2015年頭まで、本家の開発チームにて公式にInnoDBの性能改善に取り組みました。その後4年ほどデータベースに拘らずに新しい技術を用いた開発に携わりました。2019年から再び中の人に復帰しています。中の人の時の更新頻度は凄く低いと予想されます… 詳細プロフィールを表示 ► 2021 (4) ► 5月 (1) ► 3月 (1) ► 1月 (2) ▼ 2020 (3) ► 12月 (1) ► 9月 (1) ▼ 7月 (1) 次の次のリリースこそは… ► 2019 (1) ► 2月 (1) ► 2018 (5) ► 11月 (1) ► 9月 (2) ► 7月 (1) ► 3月 (1) ► 2017 (2) ► 12月 (1) ► 2月 (1) ► 2016 (3) ► 7月
概要 MySQLのUNIQUE KEYの変更がすんなりいかないということだけは記憶に残っていましたが、方法が記憶に残っていなかったので、備忘録的に記載します。 前提 以下のようなTableを想定します。 mysql> SHOW CREATE TABLE articles; CREATE TABLE `articles` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `tab_id` int(10) unsigned NOT NULL, `articles` mediumtext NOT NULL, `created_at` datetime NOT NULL, `updated_at` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `idx_tab_id` (`tab_id`) ) E
Google Cloud SQL for MySQLがダブルバッファーライトをやめて16KiBのアトミックなダイレクトI/Oを実現するまで
Google Cloud SQL for MySQLがダブルバッファーライトをやめて16KiBのアトミックなダイレクトI/Oを実現するまで まとめ AWSはre:Invent 2022でRDS MySQLの書き込みスループットが最大で2倍になる機能を発表しました。 Amazon RDS Optimized Writes enables up to 2x higher write throughput at no additional cost x86_64アーキテクチャの場合、1ページの大きさは4KiBです。 複数ページにまたがるデータをflush中に障害が起こると、一部のページだけが書き込み成功することがあります。この状態を torn write と呼びます。 torn writeを防ぐために(torn write prevention;TWP)、MySQLにはダブルバッファーという仕組
Vue.js + Node.js + Express + MySQL example: Build a full-stack CRUD Application - BezKoder
Project Structure – db.config.js exports configuring parameters for MySQL connection & Sequelize. – Express web server in server.js where we configure CORS, initialize & run Express REST APIs. – Next, we add configuration for MySQL database in models/index.js, create Sequelize data model in models/tutorial.model.js. – Tutorial controller in controllers. – Routes for handling all CRUD operations (i
「MySQL8.0 で起こる謎のデッドロックの条件を調べてみた」を data_locks・data_lock_waits テーブルで確かめてみた - Qiita
これは インフラ勉強会 Advent Calendar 2018 17 日目の記事です。 ※忘れていたので後から突っ込みました。 昨日は sahya さんだった…はずです（皆さん忙しそうですね…時期が時期だけに）。 インフラ勉強会の Advent Calendar には PostgreSQL の記事を 2 本入れたのですが、本来わたしは MySQL 側の人ですので、ここはひとつ MySQL ネタを突っ込んでおきます。 Qrunch に、 MySQL8.0 で起こる謎のデッドロックの条件を調べてみた（bluexxsun さん） という記事が掲載されており、面白そうだったので、 MySQL 5.7と8.0でロック状態を確認する（sys.innodb_lock_waitsビュー） に書いた、 **performance_schema.data_locks**テーブル **performance_
CBcloud Advent Calendar 2020の4日目を担当します、あらかきゆうじです。CBcloudではサーバーサイド & インフラエンジニアみたいな立ち位置で仕事をしております。 今回は「Amazon Aurora MySQLを使うときに知っておきたい10のこと」というタイトルの記事を書こうとしたのですが、書いてみると自分の頭の中にぼんやりとあった書きたいことが6つしかなかったことに気がついたので「Amazon Aurora MySQLを使うときに知っておきたい6つのこと」というタイトルに変更しました。 AWSのマネージドサービスであるAuroraを「マネージドの強いMySQL」ぐらいのお気持ちで使っているサーバーサイドエンジニアの方にAurora固有の特徴をある程度知ってもらえればいいな〜と思っています。 ちなみに弊社ではAuroraのMySQL互換を使っているので、今回は
この記事はミライトデザイン Advent Calendar 2021 の10日目の記事です。 本日も懲りずに乱入させていただきました。 昨日は@tkek321 さんのDockerについての記事でした。 １つ１つ丁寧に解説してくれている記事なので、ぜひご一読をおすすめします。 読んでね！ docker-laravel の Docker 構成をちゃんと理解する【docker-compose.yml 編】 本日はSQLアンチパターンのインデックスショットガンについて記事にさせていただきます。 名前がカッコイイからこの記事書きました。 インデックスショットガンって何？ インデックスショットガンとは、書籍：「SQLアンチパターン」で紹介されているアンチパターンの1つで、闇雲にインデックスを作成することを指しています。 「インデックスって性能改善にいいんでしょ？よくわからないけど、とにかくインデックス
※は十分に大きいため省略しています。また、どちらの表も各整数値型はsignedを想定しています。 データ挿入量が相当大きくない限りは、INTEGER型で足りるのであればINTEGER型で作ってしまって問題ないかもしれません。しかし、あとから足りなくなってデータ型の変更が必要になる可能性があるのであれば、最初からBIGINT型で作ってしまうことも検討したいところです。たしかにALTER TABLEでデータ型の変更は可能ではありますが、データ量の規模によっては時間がかかってしまうためです。だからといって、すべてをBIGINT型のカラムで作ってしまうのも無駄にデータ量が増えてしまうので、きちんと検討して決めることをおすすめします。 また、JOINに利用するカラムの場合は、データ型が違うと型変換が実行されるために実行が遅くなるので、極力データ型を合わせて利用したいところです。 BIGINTじゃ足り
OSSデータベース取り取り時報 第87回MySQL 8.0.31リリース、HeatWave新機能続々、EDB CEO Ed Boyajianさん対談とPostgreSQL 15リリース情報 この連載はOSSコンソーシアム データベース部会のメンバーがオープンソースデータベースの毎月の出来事をお伝えしています。 ［MySQL］2022年10月の主な出来事 2022年10月のMySQLの製品リリースは、MySQLサーバー8.0.31、5.7.40の各マイナーバージョンをはじめ、MySQL NDB Clusterや各種Connector、MySQL Shell、MySQL Workbenchなどのクライアントプログラムの商用版、およびコミュニティ版のほぼ全ての製品のマイナーバージョンアップが行われました。MySQLのマネージドサービスMySQL HeatWave Database Service
この記事は MySQL Casual Advent Calendar 2017 の7日目です。 最近、デッドロックを真剣に対応する機会があったのでその時のメモです。 デッドロックとは？ デッドロックとは「複数のトランザクションが互いがロックの開放を待ち、結果として、どの処理も先に進めなくなってしまった状態」を指す。 単にロック待ちが長時間になっているケースはデッドロックとは呼ばない。 時間 TRANSACTION(1) TRANSACTION(2) 1 BEGIN 2 BEGIN 3 UPDATE t1 SET col1 = 'session1' WHERE pk = 1; 4 UPDATE t2 SET col1 = 'session2' WHERE pk = 1; 5 UPDATE t2 SET col1 = 'session1' WHERE pk = 1; ※ TRANSACTION
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ゼロからマイクロサービスに取り組むイオン、DB運用や組織課題の解決に「TiDB」が寄与できることとは
第208回 MySQL複数値indexの制限に関しての補足 | gihyo.jp
TypeORM｜【入門】CLIでプロジェクト構築して使い方を確認 - わくわくBank
Gormの使い方についてまとめてみた - Qiita
Python用のMySQLコネクタでトランザクションの開始終了を実装する方法 - Qiita
Cloud SQL Enterprise Plusのメンテナンスはどのように実現されているか
【ChatGPT】【活用方法】DDL(SQL) から ER図を作成する
MySQL の Generated Columns のキャッチアップ
MySQLでのバルクアップデートの性能比較 - Qiita
Spring BootアプリケーションのセッションをDBで管理する - daisuzz.log
Everything You Need to Know About MySQL Partitions
PHPとMySQLを使用し画像ファイルをアップロードし、データベースに保存する
Django で楽観的排他制御を簡単に実装する方法（初級者向け） - akiyoko blog
pt-online-schema-changeを理解する - Qiita
Docker×MariaDB 環境構築 | トライフィールズ
MySQL UNIQUE KEYの変更 - Qiita
Amazon Aurora MySQLを使うときに知っておきたい6つのこと | Yuji Arakaki
インデックスショットガンで書き込み性能はどれくらい劣化するのか - Qiita
第178回 MySQLのAUTO_INCREMENTなINTEGERってどのくらいで使い切るの？ | gihyo.jp
第87回 MySQL 8.0.31リリース、HeatWave新機能続々、EDB CEO Ed Boyajianさん対談とPostgreSQL 15リリース情報 | gihyo.jp
MySQLのデッドロックについて - mita2 database life