Preface

Because I have deployed the main site and backup site of WordPress in my home data center, and arranged the mirror site on the cloud server, and successfully implemented the real-time backup and fast recovery of multiple WordPress configurations through the scheduled backup of WPvivid backup plug-in of WordPress and the scheduled synchronization function of syncthing (see article:Docker series: A detailed tutorial on how to synchronize multiple folders using Docker based on syncthingandDocker series uses Docker to set up a blog slave site based on WordPress and implement regular backup of master-slave site configuration). However, because my home broadband had problems a few days ago (not a natural failure, the game is still going on, we will talk about it after the result is out), I found that the image bed was still at home after I switched WordPress to the mirror site (it couldn't be connected even if the network was disconnected)～～, so it is not enough to just achieve redundancy for WordPress, the image bed also needs redundancy. Therefore, I spent some time to create redundancy for Chevereto's image bed on the mirror site, and then the blog was completely restored.

Therefore, I want to include Chevereto in the multi-point synchronization plan to achieve the same topology as the WordPress site: the main image bed, the backup image bed and the mirror site image bed, and when the data of the main image bed increases, the backup image bed and the mirror site image bed can also increase the data synchronously (in fact, it all comes down to laziness, I want to do it in one step ~), so this article was written.

Chevereto consists of the program itself and its corresponding "library" in the database. The pictures are stored in the program.data/imagesIn the directory, there is a database in the database used by chevereto, so to achieve data synchronization, it is necessary to synchronize the chevereto program data and the database at the same time, so it is divided into two steps to achieve: synchronization of chevereto's own data (mainly pictures) and synchronization of its corresponding database.

Synchronization of chevereto's own data

Note: This step requires Syncthing to synchronize multiple chevereto-related folders (For detailed configuration details of Syncthing multi-point synchronization, please refer to my other article:Docker series: A detailed tutorial on how to synchronize multiple folders using Docker based on syncthing, this article does not involve too much detailed configuration process, mainly because there are too many ~ ~).

This step varies depending on how Chevereto is deployed (source code deployment or docker deployment), but the core spirit is to add the Chevereto directory as a synchronization folder in Syncthing, and then synchronize between multiple Chevereto nodes through Syncthing. Because I deployed Chevereto in docker mode, this article takes the files in this mode as an example.

Since the planning of my main image storage, backup image storage, and mirror image storage nodes overlaps with the planning of WordPress, SyncThing uses the MacMini node as the main image storage node (synchronization source), and then synchronizes to the InterMini node (backup site) and Tencent Cloud Server (mirror site) nodes. Follow the steps below:

• Redeploy the docker of syncthing-macmini and use the -v parameter to map the folder corresponding to chevereto on macmini to the corresponding path in syncthing. Here I map it to the /data2 directory:
  
  

Do the same for the syncthing-intermini and syncthing-tc nodes.

Note: At this time, the Docker version of Chevereto has not been deployed on these two nodes. You can first create a folder corresponding to the Docker (note that the folder permission must be writable) to solve the synchronization problem of Chevereto data first, and then Docker can be deployed later.

• Add data2 to the synchronization folder on syncthing-macmini, and then share it with syncthing-intermini and syncthing-tc. Then accept the sharing request from syncthing-macmini on syncthing-intermini and syncthing-tc respectively and complete the addition. The final effect of sharing is as follows:
  
  
  
  
  
  
  
  
  
  At this point, the data that the docker version of chevereto needs to mount into the container has been successfully synchronized from the syncthing-macmini node to the other two nodes.

Note: Regarding the folder type, select on syncthing-macmini:

Scheduled export of the database corresponding to chevereto

In my mariadb, the library name corresponding to chevereto is called "chevereto":

This problem is actually easy to solve. Just use the directory mounted by the chevereto container on the host. Because in the previous syncthing configuration, the files in this directory are in real-time synchronization status, so the best way is to create a db subdirectory in it, and then export the chevereto library directly to this folder in the form of a sql file:

/Volumes/data/docker/chevereto/db #/Volumes/data is the writing method of macOS since Catalina version. I will not go into details here. You can modify it according to your actual environment.

2. How to export

It is very simple to export the chevereto library of mariadb. You can use the mysqldump command. Combined with the path in the previous section, the command is as follows:

The command `docker exec -u root your_database_container_name mysqldump -uroot -p your_database_password --databases the_name_of_chevereto_databases> /Volumes/data/docker/chevereto/db/chevereto.sql` will execute the command. The export path (#) should be modified according to your specific needs, as long as it's within the sync directory configured for `chevereto`. Note that the `-u` and `-p` after `mysqldump` should be the username and password directly, without spaces.

3. How often should you export?

This depends on the different needs of each person. I just keep it consistent with the synchronization cycle of WordPress automatic backup, which is set to one week. But how to achieve automatic export once a week? This varies according to the different environments used by each person. For example, there are methods for setting up scheduled tasks on macOS (launchctl and crontab, theoretically launchctl is better), but I don’t want to bother, so for the sake of laziness, I directly put the commands in the previous section into an executable script "export_cheve_database.sh" in a specific directory of macOS, put it in the macOS user directory, and then use the scheduled task of the Pagoda panel to log in regularly using SSH to execute it:

Note: To use this SSH to run scripts on a remote device, you need to configure the SSH client on the device where the Pagoda panel is located to log in to the public key of the macmini in advance (please refer to my other article:Debian series configuration ssh public key login), but some details are different in different systems, such as macos has one more step:

ssh-add ~/.ssh/id_rsa

The contents of the "export_cheve_database.sh" script on the Mac Mini are as follows:

#!/bin/sh # Manually load environment variables; this is very important, as they are not loaded by default. Also, note that environment variable filenames differ across systems. source ~/.bash_profile # Execute the command to export the Chevereto library. The export path is in the configured Chevereto synchronization directory. This ensures that the exported library will be synchronized in real-time to the corresponding directories on the Chevereto standby node and image node. docker exec -u root your_database_container_name or_id mysqldump -uroot -pyourpassword --databases chevereto > /Volumes/data/docker/chevereto/db/chevereto.sql # After execution, echo 'end''

Scheduled import of the database of the synchronized chevereto node

Database import of chevereto node

After the previous steps, we have achieved the synchronization of program data (pictures) and exported database files of Chevereto's main site, backup site, and mirror site. The last step is to automatically import the synchronized database files to the synchronized Chevereto nodes (backup site and mirror site) at a scheduled time.

This step is actually the simplest. Just deploy the task of importing the database on the backup site and the mirror site. It sounds simple, but there are some tricks in implementation. The logical process is as follows:
1. Copy the synchronized chevereto.sql from the mount directory of the chevereto container (/docker/chevereto/db) to the mount directory of the mariadb container (assuming it is /docker/mariadb/db)
2. Create a new script file "chevereto_import.sh" in the mount directory of the mariadb container (/docker/mariadb/db) with the following content:

#!/bin/sh mysql -uroot -pyourpassword chevereto < /var/lib/mysql/chevereto.sql

Note:/var/lib/mysql/is the mounted directory in the mariadb container, corresponding to the directory on the host/docker/mariadb/dbTable of contents.
3. Give execution permission to "chevereto_import.sh":

chmod +x /var/lib/mysql/chevereto_import.sh

4. Run command execution on the host machine

docker exec -u root your database container name/var/lib/mysql/chevereto_import.sh

Implementing automatic timing import

If you want to automatically run the above process at a scheduled time, you only need to create a script in the host machine (don't forget to grant permissions), the content is as follows:

#!/bin/sh docker exec -u root mariadb01 mysql -u root -pp@ssw0rd -e "DROP TABLE IF EXISTS chv_albums, chv_confirmations, chv_deletions, chv_follows, chv_images, chv_importing, chv_imports, chv_ip_bans, chv_likes, chv_locks, chv_logins, v_notifications , chv_pages, chv_queues, chv_redirects, chv_requests, chv_settings, chv_stats, chv_storage_apis, chv_storages, chv_users, chv_categories;" chevereto # clears all tables in the chevereto library. cp /docker/chevereto/db/chevereto.sql /docker/mariadb/db/01/chevereto.sql docker exec -u root mariadb01 /var/lib/mysql/chevereto_import.sh

Then run the script regularly.

Note: The first command is to clear the existing tables in the chevereto library. This is very important, otherwise the subsequent import will not be successful. Of course, you can also delete the chevererto library directly.

I won’t go into details about how to schedule scripts. Different systems have different methods, but I can still be lazy because I have installed the Pagoda panel on both the backup site and the mirror site, so I still use the scheduled task function:

That's it! Then you just need to use the same command as the main site (mainly -v parameter to mount the correct synchronization folder) on the backup site and the mirror site to create the chevereto container (and the database parameters on these points are the same, which means that the same address or name, port, root password, etc. can be used), and chevereto will work normally immediately (for the detailed construction process of chevereto image hosting, please refer to another article:Docker series uses Docker to build your own image bed based on Chevereto).

After all the trouble above, the image hosting service has realized the multi-level redundant structure of "primary site + backup site + mirror site". In addition to the same multi-level redundant structure of WordPress that I have already implemented, I am no longer afraid of the two most painful problems of home data centers: the main site is down (Macmini is washed out) and the power and network are off at home, because there are WordPress on the cloud server and the mirror site of the image hosting service, and the image hosting service can also guarantee the latest data within 7 days (the pictures themselves are automatically synchronized, which mainly refers to the frequency of database import, which can be adjusted according to your needs). From a professional perspective, I have currently realized the application hot backup and the same-city disaster recovery site within the home data center. According to the specifications of "two locations and three centers", I still lack a "remote disaster recovery" site, which I plan to achieve using hexo+github+cloudflare pages, but only the text part of the blog, after all, it has been hosted on cloudflare pages and is always online, and the "remote disaster recovery" of the image hosting service is a bit troublesome, let me think about it.

Afterword

To be honest, this article is more difficult than I thought. I thought it was very simple, but I kept encountering problems when implementing it (too many prerequisite knowledge points). In the final analysis, it was because my foundation was too poor and my knowledge was too narrow. I had a superficial understanding of many knowledge points. Only when I really needed to use it did I realize that the pot was made of iron. I had to calm down and study the details carefully.

But when I think about it this way, my previous plan for WordPress multi-point data synchronization and quick recovery needs to rely on the WPvivid backup plug-in and requires manual intervention, which is quite low. After the practice of chevereto multi-point automatic synchronization, WordPress should be able to achieve the same effect. After I write the article on Google Ads, I will study the multi-point fully automatic synchronization of WordPress.