GitLab.comはどうやって6TBのPostgreSQLを9.6から11にたった2時間で移行したのか? | DevelopersIO
EKS(Kubernetes)上にDigdag・Embulk・Redashで分析環境を構築する - Koichi Ishida blog
目次 ワーカーノードの作成 DigdagとEmbulkのDockerビルド KubernetesにDigdag/Embulkをデプロイ Redashの導入 まとめ Kubernetes上に分析環境を構築する機会があったのでどのように構築したかを紹介します。同じような構成でKubernetes上で構築するのは3回目になったので構築方法も洗練されてきました。構成は以下のようになっています。 MySQL(RDS): サービスのデータベース。ここのテーブルからBigQueryにEmbulkでデータをエクスポートします。 PostgreSQL(RDS): Digdagのデータベース。今回新たにつくりました。 Digdag: データベースのエクスポートなどを実行するタスクスケジューラ。失敗したときにリトライもできます。 Embulk: プラグインを使ってデータベースをMySQLからBigQueryにエ
What's New at AWS - Cloud Innovation & News
Amazon Aurora supports in-place upgrades from MySQL 5.6 to 5.7 Starting today, you can perform an in-place upgrade of your Amazon Aurora database cluster from MySQL major version 5.6 to 5.7. Instead of backing up and restoring the database to the new version, you can upgrade with just a few clicks in the Amazon RDS Management Console or by using the AWS SDK or CLI. Aurora MySQL 5.7 offers enhancem
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
オラクル、MySQLにOLAP用の独自インメモリデータベースエンジンを搭載、「MySQL Analytics Engine」をOracle Cloud上で提供開始
米オラクルは、Oracle Cloud上での新しいデータベースサービス「Oracle MySQL Database Service Analytics Engine」（以下、MySQL Analytics Engine）を発表しました。 オラクルは今年の9月に、最新のOracle Cloud基盤に最適化したMySQLのマネージドサービスとして「Oracle MySQL Database Service」を発表しています。 今回発表されたMySQL Analytics Engineは、このMySQL Database Serviceに大規模データ分析機能を追加するものです。 通常のデータベースエンジンであるInnoDBに対して最大で400倍高速にOLAPのクエリを実行できます。 具体的にはオラクルが独自に開発したカラム型の分散インメモリデータベースエンジンをMySQL Database Se
第134回 DDLと暗黙的なコミットについて | gihyo.jp
皆さんはMySQLを開発に利用している時に、カラム追加や変更を同時に行いたい場面によく出くわすと思います。特に、Webアプリケーションフレームワークなどで用意されているデータベーススキーマのマイグレーションツール等を利用している時に、マイグレーション途中で失敗して中途半端に適用されてしまう、なんてことがあるかもしれません。 マイグレーションが中途半端に適用されてしまった場合、マイグレーションツールでは簡単に元に戻せず、スキーマの復旧のためにmysqlでログインして手作業で復旧するはめになってしまって困った経験がある方もいるかも知れません。そういうアトミック性が欲しい時は、トランザクションを利用して…と、考えると思いますが、これは実は上手くいきません。 今回はその理由である「暗黙的なコミット」について解説していきたいと思います。 検証環境 今回は、第125回 phpMyAdminでDocke
PostgreSQLには「中途半端なサイズ」のデータを格納しないほうがいい
ウェブサイトやアプリケーションには、ユーザー名やメールアドレスといった小さなサイズのものからブログ本文といった大きなサイズのものまで多種多様なサイズのテキストが使われています。一般的にはテキストサイズによってデータベースを使い分けることはありませんが、データベースのPostgreSQLでは「中途半端なサイズ」のテキストデータを格納するとパフォーマンスの低下につながるという調査結果とその仕組みを、ソフトウェアエンジニアのHaki Benita氏が説明しています。 The Surprising Impact of Medium-Size Texts on PostgreSQL Performance | Haki Benita https://hakibenita.com/sql-medium-text-performance PostgreSQLの場合、データベースのインデックスとテーブルは
MySQL :: Employees Sample Database :: 3 Installation
The Employees database is available from Employees DB on GitHub. You can download a prepackaged archive of the data, or access the information through Git. To use the Zip archive package, download the archive and unpack it using WinZip or another tool that can read .zip files, then change location into the unpacked package directory. For example, using unzip, execute these commands: $> unzip test_
MySQL のロック範囲は実行計画で変わるという話 - mita2 database life
最近、ANDPADでデータベース周りの技術顧問をさせて頂いています。ANDPADのエンジニアの皆さんから「データベースのロックまわりを詳しく知りたい！」というお話を受けて、先日、ロック周りの社内勉強会を開催しました。 SQLでは一般的なプログラミング言語と違って、ロックの制御を明示的に記述しません。ロックは暗黙的に（自動的に）データベースが必要なロックを獲得します。データベースのロックが わかりにくい・むずかしい と言われることが多いのはこういった背景があると思います。 MySQL のロック範囲は実行計画で変わる 更新対象の行がロックされるのは予測が付く方が多いと思います。 しかし、MySQL（InnoDB）では更新対象でなくても行がロックされることがあります。 このようなサンプルデータを使って説明します。 mysql> CREATE TABLE `lockt` ( -> `pk` big
Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life
Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide
トランザクション中の文の失敗の扱いの違い - Write and Run
(読みづらいタイトルだな) ことの発端はこのツイート。 MySQLは、以下を満たさないという理解でいいのか？ エラーが出た時にPostgreSQLのようにロールバックを行わないので Atomicity（原子性）・・・トランザクションの実行結果は「全て成功」か「全て失敗」のいずれかでなければならない#mysql— imaharu (@imaharuTech) July 2, 2020 さすがの MySQL でもそこを破ってくることはないだろうと思いつつ、トランザクション野郎としてはちゃんと確かめねばならないと思い、早朝にも関わらず布団から出てラップトップを開いた(午前10時)。 実験1 以下のような docker-compose.yml と sql/script.sql を用意し、実験をする。 version: '3.3' services: db: image: mysql:8 envir
MySQL :: MySQL Terminology Updates
Why was “source” chosen? MySQL Asynchronous Replication is a change stream. Each replication configuration has a source and does not imply what role a server should have in the overall database architecture. Therefore, the use of e.g. “primary” does not fit, especially when replication is used to build database architectures topologies including bidirectional replication, multi-tiered replication,
Amazon RDS Proxy for Scalable Serverless Applications – Now Generally Available | Amazon Web Services
AWS News Blog Amazon RDS Proxy for Scalable Serverless Applications – Now Generally Available At AWS re:Invent 2019, we launched the preview of Amazon RDS Proxy, a fully managed, highly available database proxy for Amazon Relational Database Service (RDS) that makes applications more scalable, more resilient to database failures, and more secure. Following the preview of MySQL engine, we extended
PythonのORMライブラリsqlalchemyで利用可能なコネクションプーリングの実装について調べてみた | DevelopersIO
CX事業本部@大阪の岩田です。Python向けのORMライブラリsqlalchemyは標準でコネクションプーリングの実装が組み込まれており、create_engine()を呼出す際の名前付き引数poolclassの指定によってコネクションプーリングの実装を切り替えることができます。先日コネクションプーリングの実装について調べる機会があったので、内容をご紹介します。 環境 今回利用した環境です。 OS X 10.14.6 Python 3.8.2 sqlalchemy 1.3.16 pymysql 0.9.3 利用できるコネクションプーリングの実装 sqlalchemyは標準で以下のコネクションプーリングの実装を提供しています。 QueuePool NullPool SingletonThreadPool StaticPool AssertionPool 例としてNullPoolを使う場合は
バックアップと障害復旧から考える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
MySQL 8.0.18 の実装を読み解きながら簡単なストレージエンジンを自作する - それが僕には楽しかったんです。
はじめに MySQL をビルドする ストレージエンジンを自作する Example エンジンをベースにする handlerton の作成とインスタンス化 テーブルを作成する 余談・気になったところ テーブルを開く INSERT の実装 ha_tina の存在 テーブルスキャン store_lock の実装 external_lock の実装 rnd_init の実装 info の実装 extra の実装 rnd_next の実装 おわりに はじめに 卒論書くのに飽きてきて何かやりたくなったので急にストレージエンジンを書くことにしてみた。 MySQL のストレージエンジンを実装していく中で、色々できるかなと思っていたけど、やってみると MySQL の内部実装について色々知らないといけないことが多くインデックスとかトランザクションとかそういうところは実装できなかった。 github.com My
Rails アプリケーションを Cloud Run にデプロイする - こうさくきろく
Cloud Run（Cloud Run on GKE でないほう）に Rails アプリケーションをデプロイします。 デプロイは下記の流れで進めます。 Rails アプリの Docker イメージをローカルで作成して、Container Registry に Push Cloud SQL インスタンスとデータベースを作成 ローカルで Cloud SQL Proxy を使って Schema Migration を実行 Cloud Run にアプリケーションをデプロイ 今回作成したソースコードは下記においてあります。 scripts/ 以下に gcloud コマンドの実行サンプルもおいてあります。 github.com Cloud Run Cloud Run は GCP での Knative のマネージドサービスです。 cloud.google.com cloud.google.com Kna
MySQLで直感的じゃない動きをするRAND()とSYSDATE()について - なからなLife
端的にいうと SELECTのWHEREの条件の「右辺」に、RAND()やSYSDATE()のような非決定性関数を使うと、想定外のことが起こる。 戻ってくる行数が想定と異なる。 Indexが効かなくなる。（テーブルフルスキャン走る） どっちもなかなかのインパクトです。 追記：2019/05/30 PostgreSQLもMySQLと同じ挙動でした。（9.6と10系で確認） Oracleは、MySQLやPostgreSQLとは異なり、想定通りの件数が返ってきますし、Indexも効いてました。（11g R2で確認） 追記：2019/05/31 「PostgreSQLもMySQLと同じ」なのは、「ランダム関数利用時の挙動」です。日付系は調査しきれてません。 公式ドキュメントを読む限り、clock_timestamp()やtimeofday()を意図的に使わない限り、１つのSQLの中で違う日時を取り直
もし間違ってDROP DATABASEしてしまったら – area[nothing] : diary
2007/ 01 02 03 04 05 06 07 08 09 10 2006/ 01 02 03 04 05 06 07 08 09 10 11 12 2005/ 01 02 03 04 05 06 07 08 09 10 11 12 2004/ 01 02 03 04 05 06 07 08 09 10 11 12 2003/ 01 02 03 04 05 06 07 08 09 10 11 12 2002/ 01 02 03 04 05 06 07 08 09 10 11 12 2001/ 01 02 03 04 05 06 07 08 09 10 11 12 2000/ 01 02 03 04 05 06 07 08 09 10 11 12 1999/ 01 02 03 04 05 06 07 08 09 10 11 12 1998/ 01 02 03 04 05 06 07 0
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js Database with Prisma | Next-Generation ORM for SQL Databases
