育児支援ダッシュボードを支える技術 - 人間だったら考えて
この記事はなに？ 構成・実装 育児記録 室内の温湿度 現在の天気 ダッシュボード 取得情報のデータベースへの格納 ダッシュボードに何を掲出すべきか？ まとめ 参考 この記事はなに？ 以下の育児支援ダッシュボードの構築ポストに触発され、自分もダッシュボートを作ってみました。 我が家の最終形態こんな 日中妻が試す→不満・希望を夕方俺に伝達→夜俺が治すみたいなサイクルを2週間回した後の図 pic.twitter.com/PHYRx7m1MS— Dr.10(どく・とぉと読んでください) (@Dr10_TakeHiro) 2023年10月2日 現時点で、自分が作ったダッシュボードは以下のようになっています。 育児支援ダッシュボード この記事では、上記の育児支援ダッシュボードを支える技術について解説します。 構成・実装 ダッシュボードには大きく分けて以下の3つの項目を載せています。 育児記録：「ぴよロ
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
バックアップと復元 - Azure portal - Azure Database for MySQL
自動バックアップ Azure Database for MySQL サーバーは、復元機能が有効になるように、バックアップが定期的に行われます。 この機能を使用して、新しいサーバー上で、サーバーとそのすべてのデータベースを過去の特定の時点に復元できます。 前提条件 このハウツー ガイドを完了するには、次が必要です。 Azure Database for MySQL サーバーとデータベース バックアップ構成の設定 サーバーの作成時に、 [価格レベル] ウィンドウで、ローカル冗長バックアップまたは地理冗長バックアップのどちらでサーバーを構成するかを選択します。 Azure Portal でサーバーを作成するときに、 [価格レベル] ウィンドウで、使用しているサーバーのバックアップとして [ローカル冗長] または [地理冗長] のいずれかを選択します。 また、このウィンドウの [バックアップの保有
パフォーマンスのベスト プラクティス - Azure Database for MySQL - Flexible Server
重要 Azure Database for MySQL の単一サーバーは提供終了パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、「Azure Database for MySQL 単一サーバーの動作」を参照してください 。 Azure Database for MySQL フレキシブル サーバーの操作中に最高のパフォーマンスを得る方法について説明します。 Microsoft は、プラットフォームに新しい機能を追加していく中で、このセクションで詳しく説明するレコメンデーションを改善していきます。 物理的な近接 アプリケーションとデータベースを同じリージョンにデプロイしていることを確認します。 パフォーマンス
SQLの観点から「Oracle Database」「PostgreSQL」「MySQL」の特徴を整理しよう！ | アシスト
SQLの観点から「Oracle Database」「PostgreSQL」「MySQL」の特徴を整理しよう！ 企業の情報システムで利用されているRDBMSでは、近年は商用データベースだけでなくオープンソース・データベースを併用するケースも増えており、選択肢は多様化しています。ご存じの通り、SQLはRDBMS共通の言語ですが、実際は細かな記述の違いやRDBMS独自の機能が多数存在します。そのため、例えば商用データベースからオープンソース・データベースに移行したり併用したりすると、アプリケーションの改修コストや、意図した通りに動作しないといった問題が発生する場合があります。本記事では、SQLの視点からRDBMSの主な差異を紹介し、異なるRDBMSに移行する際の注意点やRDBMS選定のポイントに迫ります。
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
HAProxy v1.6を使って複数のRDS Read Replilcaに分散させる - tail my trail
RDS ReadReplicaを立てて、参照クエリを逃がすことを考える。 可用性や拡張性を考えてReadReplicaは複数台構成とした場合、RDSの仕様を考慮して設計しておく必要がある。ポイントは以下。 Read Replicaは個々にEndpoint (DNS名) を持つ。 複数Read Replicaに対してバランシングする仕組みは提供していない。 ELBは RDS (Read Replica含め) には使えない。ELBにぶら下げられるのはEC2のみ。 Read Replica各ノードの死活監視、障害時の切り離し／切り戻しを考慮する必要がある。 ということで、Read Replicaのバランシングを行うなら、自分で仕組みを用意する必要がある。 実現方法はいくつか選択肢があるが、今回はL7のバランサーとして定評のあるHAProxyを使ってみる。 Architecture with HA
広告系インフラエンジニアのtumblr • MHA導入について
概要 MySQLのMaster-Slave構成において、Masterがダウンした際、自動failover(SlaveのMasterへの昇格)を実現 昇格させるSlaveの優先度付けが可能 Masterが切り替わった際、他のSlaveの向き先も新しいSlaveへと向く 動作原理 利用時の注意/検討事項 my.cnfについて Masterに昇格しうるSlaveには、log-binオプションが必要 運用について daemon化する場合はdaemontoolsとの併用が推奨される スプリットブレイン予防のために、secondary_check_scriptパラメータをMHAのconfigに設定した方が良い masterが切り替わったことのアプリケーション通知は、master_ip_failover_script|shutdown_script を configに設定することで可能。バランサーやHA
MySQL を MHA + HAProxy で冗長化してみよう
斎藤です。こんにちは。 今日は、MySQLにてレプリケーション構成において、マスタサーバのフェイルオーバーを司るmysql-master-ha(以下、MHA)を用いる際、マスタサーバ接続先の切り替えにHAProxyを使ってみようというお話です。 ※MHAは0.53.0(公式パッケージ)、MySQLは5.5.25a(Oracle公式パッケージ)、HAProxyは1.4.22(CentOS6標準パッケージ)、OSはCentOS 6.3 x86_64を用いました。 ※MHAによる冗長化およびHAProxyによるMySQLの負荷分散の設定を経験された事がある前提で記述します。 本記事では、次の流れで話題を展開します。 フェイルオーバー時の接続先切り替え方法 構成(参考) なぜHAProxyなのか 切り替え方 2台構成の問題点 その他 コツ 設定(参考) 主にMHA+HAProxyによるフェイルオー
MySQLバイナリログの仕様 – OpenGroove
MySQLのバイナリログについて、うっすらまとめてみようかと。 RDBMSで更新ログまたはトランザクションログと呼ばれているログの機能は、 MySQLでは「バイナリログ」が担っている。 これらの内容は、「CREATE TABLE文やINSERT文といったデータベースの中身を 変更する操作を行った際の操作履歴を追跡できる形で記録した情報」であり、 コミットされたトランザクションの情報が保存される。 トランザクションログの中身はRDBMSによって異なり、「論理ロギング」と 「物理ロギング」がある。「論理ロギング」はSQL文レベルで変更履歴を管理し、 「物理ロギング」は変更があったデータブロックをバイナリイメージとして管理する。 MySQLのバイナリログは論理ロギングだが、OracleのREDOログやInnoDBログは 物理ロギングである。 バイナリログはデフォルトでは作成されないので、my.c
MHA for MySQL の概要 - Gosuke Miyashita
MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下
MySQLでカラムやインデックスの追加、削除をするときのロックの話など - (ﾟ∀ﾟ)o彡 sasata299's blog
2013年12月12日14:03 MySQL MySQLでカラムやインデックスの追加、削除をするときのロックの話など すっかり2013年も終わりに近づいてきましたね。さて、今回はMySQLでカラムやインデックスの追加、削除をするときに知っておいた方がいいかなーと思った注意点の話です。 カラムやインデックスの追加、削除を行う際にはテーブルが共有ロックされる まず、カラムやインデックスの追加、削除といったいわゆる ALTER TABLE に相当する処理を行うとテーブルが共有ロック（読み込みのみ受け付け、更新処理は受け付けないというロック）されるという話です。 この辺の話は @nippondanji さんが詳しく書かれています。 漢(オトコ)のコンピュータ道: ALTER TABLEを上手に使いこなそう。 1. テーブルをTL_WRITE_ALLOW_READロックする。このロックは特殊なロック
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TablePlus | Modern, Native Tool for Database Management
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
Why Uber Engineering Switched from Postgres to MySQL
株式会社TAP
[ThinkIT] 第6回：query_cache_sizeの違いによるパフォーマンス比較 (1/3)