mirror of https://github.com/abpframework/abp.git
Masum ULU
3 years ago
committed by
GitHub
GitHub
3100 changed files with 238320 additions and 165044 deletions
@ -1,7 +1,7 @@ |
|||
{ |
|||
"culture": "ar", |
|||
"texts": { |
|||
"AbpTitle": "إطار عمل ABP - إطار عمل تطبيق ويب مفتوح المصدر", |
|||
"AbpTitle": "قراءة جميع مشاركات المدونة", |
|||
"AbpDescription": "ABP هو إطار عمل مفتوح المصدر يركز على تطوير تطبيقات الويب القائمة على AspNet Core. لا تكرر نفسك ، ركز على كود عملك الخاص." |
|||
} |
|||
} |
|||
@ -1,7 +1,8 @@ |
|||
{ |
|||
"culture": "en", |
|||
"texts": { |
|||
"AbpTitle": "ABP Framework - Open Source Web Application Framework", |
|||
"AbpDescription": "ABP is an open source application framework focused on AspNet Core based web application development. Don't repeat yourself, focus on your own business code." |
|||
"AbpTitle": "Read All Blog Posts", |
|||
"AbpDescription": "ABP is an open source application framework focused on AspNet Core based web application development. Don't repeat yourself, focus on your own business code.", |
|||
"AbpDefinition": "ABP blog for .NET development, cross-platform, ASP.NET application templates, ABP-related news and more..." |
|||
} |
|||
} |
|||
@ -0,0 +1,8 @@ |
|||
{ |
|||
"culture": "fi", |
|||
"texts": { |
|||
"AbpTitle": "ABP Framework - avoimen lähdekoodin verkkosovelluskehys", |
|||
"AbpDescription": "ABP on avoimen lähdekoodin sovelluskehys, joka keskittyy AspNet Core -pohjaiseen verkkosovelluskehitykseen. Älä toista itseäsi, vaan keskity omaan yrityskoodiisi.", |
|||
"AbpDefinition": "ABP-blogi .NET-kehityksestä, useista alustoista, ASP.NET-sovellusmalleista, ABP:hen liittyvistä uutisista ja muusta..." |
|||
} |
|||
} |
|||
@ -1,7 +1,7 @@ |
|||
{ |
|||
"culture": "tr", |
|||
"texts": { |
|||
"AbpTitle": "ABP Framework - Açık Kaynak Web Uygulama Çerçevesi", |
|||
"AbpTitle": "Tüm Blog Yazılarını Oku", |
|||
"AbpDescription": "ABP, AspNet Core tabanlı web uygulaması geliştirmeye odaklanan açık kaynaklı bir uygulama çerçevesidir. Kendinizi tekrar etmeyin, kendi iş kodunuza odaklanın." |
|||
} |
|||
} |
|||
@ -1,7 +1,8 @@ |
|||
{ |
|||
"culture": "zh-Hans", |
|||
"texts": { |
|||
"AbpTitle": "ABP 框架 - 开源 Web 应用程序框架", |
|||
"AbpDescription": "ABP 是一个开源应用程序框架，专注于基于 AspNet Core 的 Web 应用程序开发。 Don't repeat yourself，专注于自己的业务代码。" |
|||
"AbpTitle": "阅读所有博客文章", |
|||
"AbpDescription": "ABP 是一个开源应用程序框架，专注于基于 AspNet Core 的 Web 应用程序开发。 Don't repeat yourself，专注于自己的业务代码。", |
|||
"AbpDefinition": ".NET开发的ABP博客，跨平台，ASP.NET应用程序模板，ABP相关新闻等..." |
|||
} |
|||
} |
|||
@ -0,0 +1,6 @@ |
|||
{ |
|||
"culture": "fi", |
|||
"texts": { |
|||
"Buy": "Osta" |
|||
} |
|||
} |
|||
@ -1,5 +1,6 @@ |
|||
{ |
|||
"culture": "zh-Hans", |
|||
"texts": { |
|||
"Buy": "购买" |
|||
} |
|||
} |
|||
@ -0,0 +1,6 @@ |
|||
{ |
|||
"culture": "fi", |
|||
"texts": { |
|||
"FAQ": "FAQ" |
|||
} |
|||
} |
|||
@ -0,0 +1,37 @@ |
|||
# Migrating from MS-SQL to Postgresql |
|||
|
|||
 |
|||
|
|||
## Introduction |
|||
|
|||
Database migration is a common practice for organizations that want to move from one database system to another. This can be for a variety of reasons, including cost, performance, and features. In this article, we will discuss the process of migrating a database from MS-SQL to PostgreSQL, the challenges that may arise during the migration, and how to overcome them. And we recently moved the main database of https://abp.io platform from MS-SQL to PostgreSQL. |
|||
|
|||
In our case, we decided to switch our database from Microsoft SQL Server (MS-SQL) to PostgreSQL because we wanted to move our on-premise platform to Azure. We’ve also found out that the cost of the license for MS-SQL on Azure was significantly higher than PostgreSQL. After conducting a cost-benefit analysis, we decided to migrate our database to PostgreSQL to save costs. |
|||
|
|||
Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure. |
|||
|
|||
## Challenges |
|||
|
|||
Despite using a third-party tool(DBConvert for MySQL & PostgreSQL) for the migration, we faced three main problems when exporting data to PostgreSQL. Firstly, some tables with plain text had utf-8 encoding problems. We overcame this problem by dump-restoring these tables. |
|||
|
|||
 |
|||
|
|||
|
|||
Secondly, our database had to be case-insensitive, but PostgreSQL does not have this as a default configuration. We handled it using `citext` with the ABP migration service. |
|||
|
|||
 |
|||
 |
|||
 |
|||
|
|||
|
|||
While everything was proceeding very smooth, we faced one last problem: importing binary data, such as the content of the NuGet packages. It was hard to understand that the binaries of the NuGet packages were different. Our paid commercial NuGet packages are being stored as binary data in the database. Therefore, it was the most compelling part of this migration to transfer the NuGet packages. Fortunately, we overcame the binary error. And we decided to write a custom .NET tool to move only the binary data from MS-SQL to PostgreSQL, thanks to the ABP Core team! |
|||
|
|||
|
|||
## Conclusion |
|||
|
|||
One of the benefits of using PostgreSQL is the low license costs of the Azure platform. As the main contributors of ABP, we also use ABP Framework under the hood of our abp.io websites, we could easily switch to PostgreSQL. For those who want to switch their ABP project to PostgreSQL, check out [docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL](https://docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL). We had not used any MS-SQL specific function, therefore there was no need to make any changes in the repository classes. This means that the applications that were previously using MS-SQL can seamlessly switch to PostgreSQL without any modifications. |
|||
|
|||
Thanks to the flexibility of ABP, it has [PostgreSQL package](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.PostgreSql) which is 100% compatible with PostgreSQL. This helped us to make this migration very smooth and seamless. |
|||
|
|||
In conclusion, migrating a database from MS-SQL to PostgreSQL can be challenging, but it can bring significant cost savings in the long run. By testing and fine-tuning the migration process before making the final switch, we were able to overcome the challenges we’d faced during the migration process. Thanks to the flexibility of ABP, we were able to make the transition with minimal code changes. Also we didn't see any big performance differences between MS-SQL and PostgreSQL. |
|||
|
|||
|
After Width: | Height: | Size: 63 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 410 KiB |
|
After Width: | Height: | Size: 5.7 KiB |
|
After Width: | Height: | Size: 4.5 KiB |
|
After Width: | Height: | Size: 32 KiB |
@ -0,0 +1,49 @@ |
|||
|
|||
# On-Prem to Azure: Migration of abp.io Platform to Azure |
|||
|
|||
|
|||
 |
|||
|
|||
Migrating a Kubernetes platform with a database from our own dedicated servers to Azure can be a compelling task, but it can be a necessary one to take advantage of the benefits that the cloud service offers. In this post, we will discuss the reasons for migrating from a on-premise platform to Azure, the steps taken to create and configure the [abp.io platform](https://abp.io) on Azure, and the benefits gained from the migration. |
|||
|
|||
### On-Premise Server: The old platform |
|||
|
|||
There were several reasons for migrating from the old on-premise platform to Azure. First, the Kubernetes cluster and the database were on the same Windows server. Additionally, the Linux virtual machines in Kubernetes were on the Windows server and had limited resources. Furthermore, the Kubernetes maintenance was quite challenging, which was another reason for the migration. |
|||
|
|||
### Reasons for Moving to Azure: The new platform |
|||
|
|||
The decision to move to the cloud was made to eliminate the disadvantages of the old platform. The migration to Azure meant that the resources would be independent of each other but faster in terms of communicating with each other. The platform would also take advantage of cloud security and availability. The managed Kubernetes service that Azure offers comes with autoscaling and loadbalancing, which makes the platform more reliable. Finally, the migration to Azure would provide a better quality service to global customers and the community. |
|||
|
|||
### Before Moving to Azure |
|||
|
|||
Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure.You can check the details of database migration from this article [Migrating from MS-SQL to Postgresql](https://community.abp.io/posts/migrating-from-mssql-to-postgresql-lbi5anlv). |
|||
|
|||
The platform was tested in a staging environment created on Azure with the same resources as the production environment. The staging environment was used to test and optimize the migration process, including the migration of data from the old platform to Azure, which was tested multiple times to ensure success. |
|||
|
|||
### Creating and Configuring the abp.io Platform on Azure |
|||
|
|||
Several steps were taken to create and configure the abp.io platform on Azure. [Terraform](https://www.terraform.io/) was used to create the infrastructure (VM, Private Network, AKS, Postgresql Flexible Server...), while [Ansible](https://www.ansible.com/) was used to configure the Azure resources like Terraform, Helm, Kubectl, Docker, VPN, Redis, Prometheus, Grafana, ElasticSearch, Kibana and so on.... Azure DevOps pipelines and release were used for AKS deployment. The most time-consuming part in this process was to prepare, test and optimize the terraform and ansible settings files. |
|||
|
|||
To access our platform, which is configured on a private network in Azure, we require a VPN connection. To enable this, we have installed [Wireguard](https://www.wireguard.com/) - an open source VPN service - by creating a virtual machine using Terraform and configuring it with Ansible in Azure. This approach has made the process efficient and streamlined. |
|||
|
|||
 |
|||
|
|||
The most important step was to transfer the data in both the database and Kubernetes of the volumes. rsync (remote sync commands) were used to transfer the data from Kubernetes volumes to Azure NFS through the VPN machine. Additionally, `pg_dump` and `pg_restore` were used to transfer the PostgreSQL database through the machine with VPN. |
|||
|
|||
Before the production environment, the data migration was tested many times for the staging environment. We estimated this migration to take max 1.5 hours. The ABP community was informed that there may be interruptions during the hours designated for the transition to Azure. To inform our customers and community, we created a status page before this migration. The new status page is [status.abp.io](https://status.abp.io). From now on we wil make all the infrastructural announcements on [status.abp.io](https://status.abp.io). We used [Upptime](https://upptime.js.org) which is an open-source uptime monitor and status page provider. During the migration of the production environment, the websites and databases were still up and running. After the data transfer, the only remaining step was to direct the traffic of the already standing abp.io sites to the Azure Kubernetes service via Cloudflare. |
|||
|
|||
We would like to happily state that **we were offline for only 4 minutes** during this transition. |
|||
|
|||
 |
|||
|
|||
|
|||
### Benefits of Moving to Azure |
|||
|
|||
The migration to Azure resulted in several benefits. The platform is now more reliable, scalable, secure, solid with built-in one-click backup and recovery capabilities for abp.io. Additionally, the critical resources are in a private network, making them more secure than the old environment. When we initially compared the speed of our abp.io sites before and after migrating to Azure, we were pleasantly surprised by the significant improvement in performance. To be honest, we did not expect such a speed increase. |
|||
|
|||
 |
|||
|
|||
In conclusion, migrating a Kubernetes platform with a database from on-premise to Azure is a complex process that requires careful planning and execution. However, the benefits gained from the migration make the process worthwhile. By moving to Azure, the abp.io platform now has a more reliable and available infrastructure that is more secure than the old environment. The migration also resulted in significant improvements in connection speeds, which ultimately provides a better service to global customers and the community. |
|||
|
|||
|
|||
|
|||
|
After Width: | Height: | Size: 136 KiB |
|
After Width: | Height: | Size: 142 KiB |
|
After Width: | Height: | Size: 336 KiB |
|
After Width: | Height: | Size: 142 KiB |
@ -0,0 +1,82 @@ |
|||
# ABP.IO Platform 7.1 Final Has Been Released! |
|||
|
|||
[ABP Framework](https://abp.io/) and [ABP Commercial](https://commercial.abp.io/) 7.1 versions have been released today. |
|||
|
|||
## What's New With Version 7.1? |
|||
|
|||
All the new features were already explained in detail in the [7.1 RC Announcement Post](https://blog.abp.io/abp/ABP.IO-Platform-7.1-RC-Has-Been-Published), so no need to go over them again. Check it out for more details. |
|||
|
|||
## Getting Started with 7.1 |
|||
|
|||
### Creating New Solutions |
|||
|
|||
You can create a new solution with the ABP Framework version 7.1 by either using the `abp new` command or generating the CLI command on the [get started page](https://abp.io/get-started). |
|||
|
|||
> See the [getting started document](https://docs.abp.io/en/abp/latest/Getting-Started) for more. |
|||
|
|||
### How to Upgrade an Existing Solution |
|||
|
|||
#### Install/Update the ABP CLI |
|||
|
|||
First of all, install the ABP CLI or upgrade it to the latest version. |
|||
|
|||
If you haven't installed it yet: |
|||
|
|||
```bash |
|||
dotnet tool install -g Volo.Abp.Cli |
|||
``` |
|||
|
|||
To update the existing CLI: |
|||
|
|||
```bash |
|||
dotnet tool update -g Volo.Abp.Cli |
|||
``` |
|||
|
|||
#### Upgrading Existing Solutions with the ABP Update Command |
|||
|
|||
[ABP CLI](https://docs.abp.io/en/abp/latest/CLI) provides a handy command to update all the ABP related NuGet and NPM packages in your solution with a single command: |
|||
|
|||
```bash |
|||
abp update |
|||
``` |
|||
|
|||
Run this command in the root folder of your solution. |
|||
|
|||
## Migration Guides |
|||
|
|||
This version includes a very minor breaking change and it doesn't affect most of the applications. Check [the migration guide](https://docs.abp.io/en/abp/7.1/Migration-Guides/Abp-7_1) for the details. |
|||
|
|||
## Community News |
|||
|
|||
## ABP Community Talks 2023.2 |
|||
|
|||
The next ABP Community Talks will take place on March 30, at 18:00 (UTC). |
|||
|
|||
 |
|||
|
|||
In this episode, core ABP Framework developers will discuss the benefits of using the ABP Framework as a .NET developer instead of creating your own solution from scratch. They will answer most of the common doubts about using ABP and application frameworks in general. You will better understand how ABP makes a developer’s life easier and more enjoyable while cutting production costs. We will also have a question - answer session after the talk, as always. I think this talk will be useful for every .NET developer whether they use ABP or not. |
|||
|
|||
**[CLICK HERE to register for the event and join us](https://kommunity.com/volosoft/events/abp-community-talks-20232-why-use-abp-framework-as-a-net-developer-e3254183)**. |
|||
|
|||
## Introducing the first ABP .NET Conference! |
|||
|
|||
As the ABP team, we've executed more than 10 [online events](https://community.abp.io/events) and gained a good experience of software talks. In May, we are organizing a full-featured software conference, named **ABP Dotnet Conference 2023**! |
|||
|
|||
 |
|||
|
|||
We are still organizing the speakers, talks and schedule. There will be 12 sessions about software development and .NET. These will also include a few ABP-related talks. You can **follow https://abp.io/conference website** and buy early bird tickets from now. |
|||
|
|||
### New ABP Community Posts |
|||
|
|||
There are exciting articles contributed by the ABP community as always. I will highlight some of them here: |
|||
|
|||
* [Creating Dockerfile for ABP Applications](https://community.abp.io/posts/creating-dockerfile-for-abp-applications-caj4fkxa) by [Anto Subash](https://community.abp.io/members/antosubash) |
|||
* [IdentityUser Relationship and Extending it](https://community.abp.io/posts/identityuser-relationship-and-extending-it-xtv79mpx) by [Onur Pıçakçı](https://community.abp.io/members/onurpicakci) |
|||
* [Streamline Localization in Your ABP Project](https://community.abp.io/posts/streamline-localization-in-your-abp-project-1t12rmjc) by [Salih Özkara](https://community.abp.io/members/salih) |
|||
* [.Net Microservice template with ABP](https://community.abp.io/posts/.net-microservice-template-with-abp-53r52ryy) by [Anto Subash](https://community.abp.io/members/antosubash) |
|||
|
|||
Thanks to the ABP Community for all the content they have published. You can also [post your ABP related (text or video) content](https://community.abp.io/articles/submit) to the ABP Community. |
|||
|
|||
## About the Next Version |
|||
|
|||
The next feature version will be 7.2. You can follow the [release planning here](https://github.com/abpframework/abp/milestones). Please [submit an issue](https://github.com/abpframework/abp/issues/new) if you have any problems with this version. |
|||
|
After Width: | Height: | Size: 160 KiB |
|
After Width: | Height: | Size: 329 KiB |
@ -0,0 +1,114 @@ |
|||
# Creating a Custom Status Page for abp.io with Upptime |
|||
|
|||
## Introduction |
|||
In today's digital world, providing reliable and transparent information about your platform's availability is essential to maintaining trust among your community and customers. With the growing number of abp.io users, we needed a dedicated status page [status.abp.io](https://status.abp.io/) to keep everyone informed about our platform's health. To achieve this, we utilized the open-source project [Upptime](https://upptime.js.org/) and built a custom status page on [GitHub Pages](https://pages.github.com/). In this article, we'll guide you through the process of creating our own status page and customizing it to suit our needs. |
|||
|
|||
 |
|||
|
|||
## Why we chose Upptime |
|||
[Upptime](https://github.com/upptime/upptime) is an open-source, easy-to-use, and cost-effective solution for monitoring websites and APIs. It offers essential features, such as downtime alerts, response time monitoring, and status history. We decided to use Upptime because of its compatibility with GitHub Pages, ease of customization, comprehensive [documentation ](https://upptime.js.org/docs/) and discord notifications. |
|||
|
|||
 |
|||
|
|||
#### Advantages of Upptime |
|||
* Open-source: Allows easy customization and community support. |
|||
|
|||
* GitHub Pages compatibility: Seamless integration with GitHub Pages for hosting. |
|||
|
|||
* Cost-effective: Utilizes GitHub Actions, which provides free monitoring within the GitHub Actions usage limits. |
|||
|
|||
* Comprehensive documentation: Easy-to-follow instructions for setting up and customizing the status page. |
|||
|
|||
#### Disadvantages of Upptime |
|||
* Limited monitoring capabilities: Upptime offers basic monitoring features but lacks advanced capabilities found in dedicated monitoring tools. |
|||
|
|||
* Dependence on GitHub Actions: Upptime relies on GitHub Actions, which may pose limitations for users unfamiliar with GitHub's ecosystem or those with large-scale projects. |
|||
|
|||
* No built-in alerting system: Users must rely on third-party integrations or custom solutions for notifications, requiring additional configuration. |
|||
|
|||
* Limited customization options: Upptime allows for some customization, but options are limited compared to comprehensive monitoring platforms. |
|||
|
|||
* Self-hosted limitations: As a self-hosted solution, users are responsible for maintaining and managing their own infrastructure, which may not be ideal for those who prefer a fully managed monitoring solution. |
|||
|
|||
|
|||
## How to set up the status page on GitHub Pages |
|||
To get started with our custom status page, we followed the instructions in the [Upptime documentation](https://upptime.js.org/docs/). Here's a summary of the steps we took: |
|||
|
|||
* Fork the Upptime [template repository](https://github.com/upptime/upptime) to our own GitHub account as [abpio-status](https://github.com/abpframework/abpio-status). |
|||
|
|||
* Configure the GitHub Actions workflow. We configured the GitHub Actions workflow by adding the following lines to the [`.github/workflows/uptime.yml`](https://github.com/abpframework/abpio-status/blob/master/.github/workflows/uptime.yml) |
|||
|
|||
* Add the monitored endpoints. We added the monitored endpoints (our abp.io websites) to the [.upptimerc.yml](https://github.com/abpframework/abpio-status/blob/master/.upptimerc.yml) file. This file is located in the root of the repository and contains a list of URLs that Upptime monitors. |
|||
|
|||
```yaml |
|||
sites: |
|||
- name: abp.io |
|||
url: https://abp.io/health-status |
|||
- name: community.abp.io |
|||
url: https://community.abp.io/health-status |
|||
- name: commercial.abp.io |
|||
url: https://commercial.abp.io/health-status |
|||
- name: nuget.abp.io |
|||
url: https://nuget.abp.io/health-status |
|||
- name: docs.abp.io |
|||
url: https://docs.abp.io/health-status |
|||
- name: support.abp.io |
|||
url: https://support.abp.io/health-status |
|||
- name: blog.abp.io |
|||
url: https://blog.abp.io/health-status |
|||
- name: commercial-demo.abp.io |
|||
url: https://commercial-demo.abp.io/health-status |
|||
``` |
|||
* Enable GitHub Pages. Finally, we enabled GitHub Pages for our forked repository by going to the repository's settings and selecting the gh-pages branch as the source. This made our status page accessible at [status.abp.io](https://status.abp.io/). |
|||
|
|||
## Customizing the status page |
|||
|
|||
After setting up the default Upptime status page, we focused on customizing it to align with our brand and provide a consistent experience for our community and customers. We made the following changes: |
|||
|
|||
* Updating the logo and favicon. We replaced the default logo and favicon with our own abp.io branded assets. This involved adding the new image files to the repository and updating the references in the `.upptimerc.yml` file: |
|||
|
|||
* Customizing the color scheme and typography. We customized the color scheme and typography to match our corporate identity by editing the `.upptimerc.yml` file: |
|||
|
|||
```yaml |
|||
status-website: |
|||
theme: dark |
|||
# Add your custom domain name, or remove the `cname` line if you don't have a domain |
|||
# Uncomment the `baseUrl` line if you don't have a custom domain and add your repo name there |
|||
cname: status.abp.io |
|||
# baseUrl: /abpio-status |
|||
logoUrl: https://commercial.abp.io/assets/svg/abp-logo-light.svg |
|||
favicon: https://raw.githubusercontent.com/abpframework/abpio-status/master/assets/abp-logo-without-text.svg |
|||
faviconSvg: https://raw.githubusercontent.com/abpframework/abpio-status/master/assets/abp-logo-without-text.svg |
|||
``` |
|||
## Creating GitHub Issues for Maintenance Information on status.abp.io |
|||
|
|||
To provide maintenance information for your status page, you can create GitHub issues in your repository. This allows you to inform your users about planned downtime or ongoing maintenance work. |
|||
|
|||
 |
|||
|
|||
## Discord Notifications |
|||
|
|||
### Create a Discord Webhook |
|||
|
|||
To set up Discord notifications for your status.abp.io status page using [Upptime documentation](https://upptime.js.org/docs/notifications#discord), follow these steps: |
|||
|
|||
* In Discord, go to "Server Settings" > "Integrations" > "Create Webhook." |
|||
* Customize the Webhook name, choose a channel, and copy the Webhook URL. |
|||
|
|||
### Configure GitHub Actions |
|||
* In your Upptime repository, go to the "Settings" tab. |
|||
* Click on "Secrets" and then "New repository secret." |
|||
* Add secret: Name it DISCORD_WEBHOOK_URL and paste the Webhook URL as the value. |
|||
* Add environment variables NOTIFICATION_DISCORD_WEBHOOK and NOTIFICATION_DISCORD set it to true. |
|||
|
|||
Your status page will now send notifications to your Discord channel whenever there's a change in your platform's status. |
|||
|
|||
 |
|||
|
|||
|
|||
## Conclusion |
|||
If your primary goal is to create a simple, cost-effective status page with basic monitoring features, Upptime is an excellent choice. Its open-source nature, seamless integration with GitHub Pages, and comprehensive documentation make it a user-friendly option. |
|||
|
|||
If you require advanced monitoring capabilities or prefer a fully managed monitoring solution, you may want to explore dedicated monitoring tools, such as Pingdom, Uptime Robot, or Datadog. These tools typically offer more robust monitoring features, built-in alerting systems, and customizable dashboards. |
|||
|
|||
Creating a custom status page for abp.io using Upptime and GitHub Pages proved to be an efficient and cost-effective solution. By following the documentation and customizing the template, we were able to provide our community and customers with a reliable source of information about our platform's availability. With this new status page [status.abp.io](https://status.abp.io/), we can continue to build trust and transparency as our platform grows and evolves. |
|||
|
After Width: | Height: | Size: 148 KiB |
|
After Width: | Height: | Size: 394 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 212 KiB |
@ -0,0 +1,37 @@ |
|||
# Migrating from MS-SQL to Postgresql |
|||
|
|||
 |
|||
|
|||
## Introduction |
|||
|
|||
Database migration is a common practice for organizations that want to move from one database system to another. This can be for a variety of reasons, including cost, performance, and features. In this article, we will discuss the process of migrating a database from MS-SQL to PostgreSQL, the challenges that may arise during the migration, and how to overcome them. And we recently moved the main database of https://abp.io platform from MS-SQL to PostgreSQL. |
|||
|
|||
In our case, we decided to switch our database from Microsoft SQL Server (MS-SQL) to PostgreSQL because we wanted to move our on-premise platform to Azure. We’ve also found out that the cost of the license for MS-SQL on Azure was significantly higher than PostgreSQL. After conducting a cost-benefit analysis, we decided to migrate our database to PostgreSQL to save costs. |
|||
|
|||
Before migrating to Azure, we decided to switch our database from MS-SQL to PostgreSQL on-premise first. This gave us the opportunity to test and fine-tune the migration process before making the final switch to Azure. |
|||
|
|||
## Challenges |
|||
|
|||
Despite using a third-party tool(DBConvert for MySQL & PostgreSQL) for the migration, we faced three main problems when exporting data to PostgreSQL. Firstly, some tables with plain text had utf-8 encoding problems. We overcame this problem by dump-restoring these tables. |
|||
|
|||
 |
|||
|
|||
|
|||
Secondly, our database had to be case-insensitive, but PostgreSQL does not have this as a default configuration. We handled it using `citext` with the ABP migration service. |
|||
|
|||
 |
|||
 |
|||
 |
|||
|
|||
|
|||
While everything was proceeding very smooth, we faced one last problem: importing binary data, such as the content of the NuGet packages. It was hard to understand that the binaries of the NuGet packages were different. Our paid commercial NuGet packages are being stored as binary data in the database. Therefore, it was the most compelling part of this migration to transfer the NuGet packages. Fortunately, we overcame the binary error. And we decided to write a custom .NET tool to move only the binary data from MS-SQL to PostgreSQL, thanks to the ABP Core team! |
|||
|
|||
|
|||
## Conclusion |
|||
|
|||
One of the benefits of using PostgreSQL is the low license costs of the Azure platform. As the main contributors of ABP, we also use ABP Framework under the hood of our abp.io websites, we could easily switch to PostgreSQL. For those who want to switch their ABP project to PostgreSQL, check out [docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL](https://docs.abp.io/en/abp/latest/Entity-Framework-Core-PostgreSQL). We had not used any MS-SQL specific function, therefore there was no need to make any changes in the repository classes. This means that the applications that were previously using MS-SQL can seamlessly switch to PostgreSQL without any modifications. |
|||
|
|||
Thanks to the flexibility of ABP, it has [PostgreSQL package](https://www.nuget.org/packages/Volo.Abp.EntityFrameworkCore.PostgreSql) which is 100% compatible with PostgreSQL. This helped us to make this migration very smooth and seamless. |
|||
|
|||
In conclusion, migrating a database from MS-SQL to PostgreSQL can be challenging, but it can bring significant cost savings in the long run. By testing and fine-tuning the migration process before making the final switch, we were able to overcome the challenges we’d faced during the migration process. Thanks to the flexibility of ABP, we were able to make the transition with minimal code changes. Also we didn't see any big performance differences between MS-SQL and PostgreSQL. |
|||
|
|||
|
After Width: | Height: | Size: 63 KiB |
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue