I recently had an opportunity to migrate a customer from a physical server into Amazon’s RDS environment. In this particular case the customers’ platform makes extensive use of MySQL triggers and views. I came across two significant issues that prevented me from following Amazon’s documentation, which basically states “use mysqldump” but doesn’t call out a specific method of dealing with MySQL triggers and views.
Amazon Relational Database Service (Amazon RDS) is a great platform if you’re looking for complete hands-off management of your MySQL environment, but comes at a cost in the area of flexibility, i.e. you don’t have SUPER privilege and this brings up additional challenges.
- You need to ensure you set log_bin_trust_function_creators=1 ( by default this is off, 0).
- You need to clean up your mysqldump syntax.
#1 is easy, you simply make a configuration change within the Amazon RDS GUI on the node’s Parameter Group to set log_bin_trust_function_creators=1 and then a restart of your Amazon RDS node. The restart is required since without the SUPER privilege you lose access to changing DYNAMIC variables on the fly. #2 is a little more complex. If you go with vanilla mysqldump (from say a 5.5 mysqldump binary) on a schema that has triggers and views, you will see error 1227, something like this:
ERROR 1227 (42000) at line 27311: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
ERROR 1227 ( 42000 ) at line 27311 : Access denied ; you need ( at least one of ) the SUPER privilege ( s ) for this operation |
You’re seeing this message because MySQL in Amazon RDS doesn’t provide the SUPER privilege, and thus you cannot set up a trigger or view to run as a different user — only a user with SUPER can do that.
mysqldump will generate syntax for a trigger like this:
DELIMITER ;;/*!50003 CREATE*/ /*!50017 DEFINER=`root`@`%`*/ /*!50003 TRIGGER `after_insert_lead` AFTER INSERT ON `leads` FOR EACH ROW BEGINUPDATE analytics.mapping SET id_lead = NEW.id_lead WHERE mc_email = NEW.email;END */;;DELIMITER ;
DELIMITER ; ; / * ! 50003 CREATE * / / * ! 50017 DEFINER = ` root ` @ ` % ` * / / * ! 50003 TRIGGER ` after_insert_lead ` AFTER INSERT ON ` leads ` FOR EACH ROW BEGIN UPDATE analytics .mapping SET id_lead = NEW .id_lead WHERE mc_email = NEW .email ; END * / ; ; DELIMITER ; |
and for a view like this:
/*!50001 CREATE ALGORITHM=UNDEFINED *//*!50013 DEFINER=`web`@`%` SQL SECURITY DEFINER *//*!50001 VIEW `admin_user_view` AS SELECT ...
/ * ! 50001 CREATE ALGORITHM = UNDEFINED * / / * ! 50013 DEFINER = ` web ` @ ` % ` SQL SECURITY DEFINER * / / * ! 50001 VIEW ` admin_user_view ` AS SELECT . . . |
The problem is in the “DEFINER” lines.
Here’s one method that worked for me:
- Identify all the DEFINER lines in your schema. I found it helpful to dump out a –no-data and then weed through that to get a unique list of the DEFINER lines
- Create a sed line for each unique DEFINER line (see my example in a moment)
- Include this sed line in your dump/load script
Here’s what my sed matches looked like:
sed-e 's//*!50017 DEFINER=`root`@`localhost`*///'-e 's//*!50017 DEFINER=`root`@`%`*///'-e 's//*!50017 DEFINER=`web`@`%`*///'-e 's//*!50017 DEFINER=`cron`@`%`*///'-e 's//*!50013 DEFINER=`cron`@`%` SQL SECURITY DEFINER *///'-e 's//*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER *///'-e 's//*!50013 DEFINER=`root`@`%` SQL SECURITY DEFINER *///'-e 's//*!50013 DEFINER=`web`@`%` SQL SECURITY DEFINER *///'
sed - e 's//*!50017 DEFINER=`root`@`localhost`*///' - e 's//*!50017 DEFINER=`root`@`%`*///' - e 's//*!50017 DEFINER=`web`@`%`*///' - e 's//*!50017 DEFINER=`cron`@`%`*///' - e 's//*!50013 DEFINER=`cron`@`%` SQL SECURITY DEFINER *///' - e 's//*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER *///' - e 's//*!50013 DEFINER=`root`@`%` SQL SECURITY DEFINER *///' - e 's//*!50013 DEFINER=`web`@`%` SQL SECURITY DEFINER *///' |
Note: the example above won’t directly work due to WordPress “helpfully” stripping my text… you need to escape the forward slashes and asterisks.
A big caveat: this method is akin to a brute force method of getting your data into Amazon RDS — you’ve lost the elegance & security of running your triggers and views as separate defined users within the database — they are all now going to run as the user you loaded them in as. If this is a show-stopper for you, contact Percona and I’d be happy to take on your case and develop a more comprehensive solution.
Now all that’s left is to integrate this into your dump flow. Something like this should work:
mysqldump--host=source| sed-e ... lots of lines| mysql--host=destination
mysqldump -- host = source | sed - e . . . lots of lines | mysql -- host = destination |
I hope this helps someone!

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1)タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2)キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3)行はスキャンされた行の数を推定し、クエリのパフォーマンスに影響します。 4)追加の情報を最適化する必要があるというFilesortプロンプトを使用するなど、追加情報を提供します。

Temporaryを使用すると、MySQLクエリに一時テーブルを作成する必要があることが示されています。これは、異なる列、またはインデックスされていない列を使用して順番に一般的に見られます。インデックスの発生を回避し、クエリを書き直し、クエリのパフォーマンスを改善できます。具体的には、expliect出力に使用を使用する場合、MySQLがクエリを処理するために一時テーブルを作成する必要があることを意味します。これは通常、次の場合に発生します。1)個別またはグループビーを使用する場合の重複排除またはグループ化。 2)Orderbyに非インデックス列が含まれているときに並べ替えます。 3)複雑なサブクエリを使用するか、操作に参加します。最適化方法には以下が含まれます。1)OrderbyとGroupB

MySQL/INNODBは、4つのトランザクション分離レベルをサポートしています。 1.ReadunCommittedは、知らないデータを読み取ることができます。 2。読み込みは汚い読み取りを回避しますが、繰り返しのない読みが発生する可能性があります。 3. RepeatablerEadはデフォルトレベルであり、汚い読み取りと非回復不可能な読みを避けますが、幻の読み取りが発生する可能性があります。 4. Serializableはすべての並行性の問題を回避しますが、同時性を低下させます。適切な分離レベルを選択するには、データの一貫性とパフォーマンス要件のバランスをとる必要があります。

MySQLは、Webアプリケーションやコンテンツ管理システムに適しており、オープンソース、高性能、使いやすさに人気があります。 1)PostgreSQLと比較して、MySQLは簡単なクエリと高い同時読み取り操作でパフォーマンスが向上します。 2)Oracleと比較して、MySQLは、オープンソースと低コストのため、中小企業の間でより一般的です。 3)Microsoft SQL Serverと比較して、MySQLはクロスプラットフォームアプリケーションにより適しています。 4)MongoDBとは異なり、MySQLは構造化されたデータおよびトランザクション処理により適しています。

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

MySQL学習パスには、基本的な知識、コアの概念、使用例、最適化手法が含まれます。 1)テーブル、行、列、SQLクエリなどの基本概念を理解します。 2)MySQLの定義、作業原則、および利点を学びます。 3)インデックスやストアドプロシージャなどの基本的なCRUD操作と高度な使用法をマスターします。 4)インデックスの合理的な使用や最適化クエリなど、一般的なエラーのデバッグとパフォーマンス最適化の提案に精通しています。これらの手順を通じて、MySQLの使用と最適化を完全に把握できます。

MySQLの実際のアプリケーションには、基本的なデータベース設計と複雑なクエリの最適化が含まれます。 1)基本的な使用法:ユーザー情報の挿入、クエリ、更新、削除など、ユーザーデータの保存と管理に使用されます。 2)高度な使用法:eコマースプラットフォームの注文や在庫管理など、複雑なビジネスロジックを処理します。 3)パフォーマンスの最適化:インデックス、パーティションテーブル、クエリキャッシュを使用して合理的にパフォーマンスを向上させます。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

AtomエディタMac版ダウンロード
最も人気のあるオープンソースエディター

メモ帳++7.3.1
使いやすく無料のコードエディター

ZendStudio 13.5.1 Mac
強力な PHP 統合開発環境

VSCode Windows 64 ビットのダウンロード
Microsoft によって発売された無料で強力な IDE エディター

WebStorm Mac版
便利なJavaScript開発ツール
