Skip to content

Home

  • in podcast
  • 2 min read

Migrating WordPress MySQL Database to AWS RDS

Hello everyone, and welcome to another episode of Continuous Improvement. I'm your host, Victor, and today we have an exciting topic to discuss - migrating your local WordPress MySQL database to Amazon Web Services Relational Database Service, also known as RDS. If you've been considering this migration for improved performance, database scalability, and easier maintenance, then you've come to the right place. So let's dive right into it.

The first step is to navigate to the AWS console and choose RDS. From there, you'll need to create a MySQL database. Simply fill in the form as shown, including the DB Instance Identifier, Master Username, and Master Password. Most of the settings can be left at their default values, including the default VPC. If you're unsure, don't worry, we'll guide you through the process.

Next, it's time to back up your existing WordPress database. SSH into your WordPress instance and use the command mysqldump -u root -p [YourDatabaseName] > backup.sql to create a backup of your database. Remember to replace [YourDatabaseName] with the actual name of your database, such as bitnami_wordpress. This backup file will be crucial in the migration process.

Now that you've backed up your database, it's time to import it into your newly created AWS RDS instance. Use the command mysql -u admin -p -h [RDS_ENDPOINT] -D wordpress < backup.sql to import the backup. Just remember to replace admin and [RDS_ENDPOINT] with your own values. If you encounter any issues during this step, we've got your back.

In case you come across an error stating "ERROR 1049 (42000): Unknown database 'wordpress'," it means your wordpress database hasn't been created yet. Don't worry, it's an easy fix. Start by connecting to the database using mysql -h [RDS_ENDPOINT] --user=admin --password=[YourPassword]. Once connected, create a new database with the command mysql> CREATE DATABASE wordpress;. Make sure you exit MySQL after creating the database.

Lastly, you'll need to edit the wp-config.php file in your WordPress EC2 instance. This file is typically located in your WordPress directory, such as /home/bitnami/apps/wordpress/htdocs if you're using Bitnami. Update the values for DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to match your newly created RDS instance. Once you've made the changes, save the file, and you're all set!

And that's it! You've successfully migrated your local WordPress MySQL database to AWS RDS. Now you can enjoy improved performance, scalability, and easier maintenance of your website. If you have any questions or need further assistance, feel free to reach out. We're here to help you every step of the way.

Thank you all for tuning in to this episode of Continuous Improvement. I hope you found this guide helpful and that it inspires you to take advantage of the benefits AWS RDS can offer for your WordPress database. Stay tuned for more episodes focused on helping you improve your workflows, technology, and more. I'm Victor, your host, signing off. Until next time!

  • in zh
  • 2 min read

將WordPress MySQL資料庫遷移到AWS RDS

在這篇文章中，我將說明如何將您本地的WordPress MySQL資料庫遷移到Amazon Web Services（AWS）關聯性資料庫服務（RDS）。你可能會想要這樣做以獲取以下好處：

  1. 改善性能，因為您的資料庫將與在EC2實例上運行的資源分開。
  2. 能夠橫向伸縮您的網站，允許多個EC2實例連接到同一個資料庫。
  3. 更容易進行資料庫維護和升級任務。

信服了嗎？下面是達成此次遷移的步驟：

首先，導航到AWS控制台並選擇RDS。建立一個MySQL資料庫，如下圖所示填寫表單：

DB實例識別碼： wordpress 主用戶名： admin 主密碼： [YourChoice]

您可以將大多數設置保留為其預設值，包括預設的VPC。

其次，編輯這個新建的資料庫的安全組。選擇資料庫，導航至連接和安全標籤，並選擇安全組。在入站規則標籤中，編輯入站規則以移除預設設定並選擇類型：MySQL，協議：TCP，以及端口範圍：3306。

在來源部分，您可以選擇與您的WordPress EC2實例相關聯的安全組，或者輸入您自己的IP地址。如果您還未創建您的WordPress EC2實例，現在你可以做，或者只需從市場使用Bitnami WordPress。

第三，SSH進入您的WordPress實例，並用此命令備份您現有的WordPress資料庫：

    mysqldump -u root -p [YourDatabaseName] > backup.sql

將[YourDatabaseName]替換為您的資料庫名稱，例如bitnami_wordpress。應在您的現有目錄中創建backup.sql文件。通過運行命令將此文件導入到您新建的AWS RDS實例：

    mysql -u admin -p -h [RDS_ENDPOINT] -D wordpress < backup.sql

將admin和 [RDS_ENDPOINT]替換為您自己的值。如果您遇到如下的錯誤：

    ERROR 1049 (42000): Unknown database 'wordpress'

這表示您的wordpress資料庫尚未被創建。首先，用以下命令連接到資料庫：

    mysql -h [RDS_ENDPOINT] --user=admin --password=[YourPassword]

一旦連接到MySQL，就用以下命令創建一個新的資料庫：

    mysql> CREATE DATABASE wordpress;
    Query OK, 1 row affected (0.00 sec)
    mysql> exit;
    Bye

最後，編輯您的WordPress EC2實例中的wp-config.php文件。該文件通常位於您的WordPress目錄中，例如倘若您使用的是Bitnami，那麼它位於/home/bitnami/apps/wordpress/htdocs。更新下列值：

    /** The name of the database for WordPress */
    define( 'DB_NAME', 'wordpress' );

    /** MySQL database username */
    define( 'DB_USER', 'admin' );

    /** MySQL database password */
    define( 'DB_PASSWORD', '[YourPassword]' );

    /** MySQL hostname */
    define( 'DB_HOST', '[RDS_ENDPOINT]' );

使用您自己的值替換占位符並保存文件。更改應立即生效。

完成。如果您有任何問題，請隨時聯繫我。

  • 1 min read

Removing .DS_Store Files from Git Repositories

If you are a Mac user who also uses Git, you might accidentally commit a .DS_Store file. This could confuse your Windows colleagues, who may wonder what these files do and why you've committed them.

First, what is a .DS_Store file? DS stands for Desktop Services, and these files are used by Macs to determine how to display folders when you open them. For example, they store custom attributes like the positions of icons. These files are created and maintained by the Finder application on a Mac, and are normally hidden.

These .DS_Store files are not useful to Windows users and do not need to be committed to your GitHub repository. To remove existing .DS_Store files from your repository, run the following command:

    find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

Afterwards, commit the changes to remove those files and push to the remote repository. To prevent these files from being added again, edit your .gitignore file and add the following line:

    .DS_Store

Doing so will address any concerns your colleagues may have.

  • in podcast
  • 2 min read

Removing .DS_Store Files from Git Repositories

Welcome back to another episode of Continuous Improvement, the podcast where we discuss tips and tricks for enhancing your productivity and problem-solving abilities. I'm your host, Victor, and in today's episode, we'll be addressing a common issue faced by Mac users who also use Git.

If you're a Mac user who has accidentally committed a .DS_Store file, you might be wondering why this is a problem and how it can confuse your Windows colleagues. Well, fear not, because today I'll be sharing some insights on what these files are and how you can avoid committing them.

So, what exactly is a .DS_Store file? The 'DS' in .DS_Store stands for Desktop Services, and these files are used by Macs to determine how to display folders when you open them. They store custom attributes such as the positions of icons and are created and maintained by the Finder application on a Mac. Normally, these files remain hidden from view.

However, for Windows users, these .DS_Store files aren't useful and can cause confusion when they find them in a Git repository. Fortunately, there's a straightforward solution to remove these files from your repository.

To remove existing .DS_Store files, you'll need to run a simple command in your terminal. Here's what you need to type:

    find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

This command will find all the .DS_Store files in your repository and remove them. Remember to commit the changes and push them to your remote repository to ensure these files are permanently removed.

But how do you prevent .DS_Store files from being added again in the future? It's simple! You just need to edit your .gitignore file and add the following line:

    .DS_Store

By adding this line to your .gitignore file, you're telling Git to ignore any .DS_Store files that are present in your repository.

By following these steps, you'll address any concerns your Windows colleagues may have about these files and maintain a cleaner, more organized Git repository.

That concludes today's episode of Continuous Improvement. I hope you found this information valuable and will be able to implement these steps in your own Git workflow. Thank you for tuning in, and remember to keep striving for continuous improvement!

  • in zh
  • 1 min read

從 Git 倉庫中移除 .DS_Store 文件

如果你是一個同時使用 Mac 和 Git 的用戶，你可能會無意間提交 .DS_Store 文件。這可能會讓你的 Windows 同事感到困惑，他們可能不清楚這些文件的用途，也不明白你為何要提交它們。

首先，什麼是 .DS_Store 文件？ DS 代表桌面服務（Desktop Services），這些文件被 Mac 用來確定當你打開它們時如何顯示文件夾。例如，它們存儲自定義屬性，如圖標的位置。這些文件由 Mac 的 Finder 應用程序創建並維護，並且通常是隱藏的。

這些 .DS_Store 文件對 Windows 用戶無益，也不需要提交到你的 GitHub 倉庫。要從你的倉庫中移除現有的 .DS_Store 文件，執行以下命令：

    find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

然後，提交更改以移除這些文件，並推送到遠程倉庫。為了防止這些文件再次被添加，編輯你的 .gitignore 文件，並添加以下行：

    .DS_Store

這樣做將避免你的同事產生任何疑慮。

  • 1 min read

Ignoring Already Modified Files in Git

I've encountered a rare scenario where a file has been modified, but I don't want to commit this change to Git. There are various methods to achieve this, such as using a .gitignore file. However, this approach doesn't work if the file is already being tracked.

The solution is to manually ignore the file by executing the following command:

    git update-index --assume-unchanged <file path>

To start tracking the file again, you can revert this action by using the following command:

    git update-index --no-assume-unchanged <file path>

Feel free to reach out if you have any questions.

  • in podcast
  • 2 min read

Ignoring Already Modified Files in Git

Welcome to the Continuous Improvement podcast, where we explore tips, tricks, and strategies for enhancing your personal and professional growth. I'm your host, Victor, and in today's episode, we'll be discussing how to handle a rare scenario in Git when you want to modify a file without committing the changes.

Have you ever found yourself in a situation where you need to modify a file, but you don't want to include those changes in your Git commit? Perhaps you're experimenting with some code, or you have local configuration changes that are specific to your environment. Well, there's actually a solution for this, and today we'll be diving into it.

Now, typically, when you want to exclude a file or a directory from being tracked by Git, you would use the .gitignore file. However, this method won't work if the file is already being tracked. So what should we do in such cases?

The solution lies in the git update-index command. By using this command, we can manually ignore specific files without modifying our .gitignore file. Let me walk you through the process.

To ignore a file and prevent it from being committed, you need to execute the following command in your Git terminal:

    git update-index --assume-unchanged <file path>

Let's break this down. --assume-unchanged is the flag used to tell Git to ignore the file, and <file path> refers to the specific file you want to exclude. By executing this command, Git will no longer consider any changes made to that file when you're committing your code.

Now, what if you want to start tracking the file again and include its changes in future commits? No worries. You can simply revert this action by using the following command:

    git update-index --no-assume-unchanged <file path>

So, in essence, this command undoes the ignore action and allows Git to track any future modifications you make to the file.

It's important to note that while using --assume-unchanged, if you make any changes to the file and try to switch branches, Git might prompt you to either stash or discard those changes. So, be cautious and ensure you're aware of the potential consequences.

And there you have it - a simple and effective way to modify a file without committing the changes to Git. Remember to use the git update-index command with the --assume-unchanged flag to ignore the file, and the --no-assume-unchanged flag to revert it.

I hope you found this tip useful, and if you have any questions or need further clarification, feel free to reach out. The power of Git lies in its flexibility, and it's always good to know these tricks that can make your version control workflow smoother.

That wraps up today's episode of Continuous Improvement. Thank you so much for tuning in and joining me on this journey of growth. If you enjoyed the show, don't forget to subscribe and leave a review. Stay tuned for more insights and strategies to help you continuously improve. Until next time, I'm Victor, signing off.

  • in zh
  • 1 min read

在Git中忽略已修改的文件

我遇到了一種罕見的情況，一個文件已經被修改，但是我不想將這個變更提交給Git。有各種方法可以實現這一點，比如使用.gitignore文件。然而，如果文件已經被追蹤，這種方法就不起作用。

解決方案是通過執行以下命令來手動忽略文件：

    git update-index --assume-unchanged <文件路徑>

要再次追蹤文件，您可以通過使用以下命令來撤消此操作：

    git update-index --no-assume-unchanged <文件路徑>

如果您有任何問題，請隨時聯繫我。

  • 1 min read

Find and Kill Processes Locking Specific Ports on a Mac

Problem: Sometimes, when you start a local Node.js server, it may continue running in the background. If you try to start the server again, you may encounter an error indicating that the port (e.g., 8080) is already in use and locked:

    throw er; // Unhandled 'error' event
    Error: listen EADDRINUSE 127.0.0.1:8080

Solution: You can use the lsof command to identify the process locking the port:

    lsof -n -i4TCP:8080

Alternatively, you can replace 8080 with the specific port number you want to investigate. This will display a list of processes currently using that port. Identify the process you wish to terminate (for example, node running with PID 6709) and execute the following command to kill it:

    kill -9 <PID>

Finally, restart your server. It should run normally once the port has been freed.

  • in podcast
  • 2 min read

Find and Kill Processes Locking Specific Ports on a Mac

Welcome to "Continuous Improvement," the podcast where we explore tips, tricks, and solutions for overcoming development hurdles. I'm your host, Victor, and in today's episode, we'll be discussing a common issue many developers encounter while working with Node.js servers: the dreaded port lock error.

Have you ever tried to start a local Node.js server only to find out that the port you want to use is already in use and locked? It can be quite frustrating, but fear not, because today we have a solution for you.

The problem occurs when you try to start your server and receive an error message that says, "Error: listen EADDRINUSE..." followed by the IP address and port number. But worry not, there's a way to identify which process is locking that port.

One method is to utilize the command-line tool called lsof. Simply open your terminal, and type in lsof -n -i4TCP:<port>. Replace <port> with the specific port number you want to investigate, such as 8080.

Once you execute this command, you'll be provided with a list of processes currently using that port. Take note of the process you wish to terminate. For example, you might see a process like node running with a PID (Process ID) of 6709.

Now comes the moment of truth. Execute the following command to kill the process and free up the locked port: kill -9 <PID>. Remember to replace <PID> with the actual Process ID you want to terminate, in this case, 6709.

Once you've successfully terminated the process, you're almost out of the woods. Now you can restart your server, and it should run normally without encountering the port lock error.

And there you have it! A simple yet effective solution for tackling the port lock issue in Node.js. Remember to use the lsof command to identify the process locking the port, and then terminate it using kill -9 <PID>.

That concludes today's episode of "Continuous Improvement". I hope this solution will help you overcome any port-related obstacles you may encounter in your development journey. Thanks for listening, and until next time, keep striving for continuous improvement in your coding endeavors.