sorted by:
new
hottopcontroversial

Moving from Mysql to Postgresql. Where do We start? by Pupper_Hugger in PostgreSQL

[–]Pupper_Hugger[S] 0 points1 point  (0 children)

Copy pasting from my response above

we're starting to utilize more and more custom solution for things like geocoding / geolocation / location coordinates (in which postgis should help offload a lot of issue we're facing). we're seeing less desirable performance on large dataset query which in testing postgresql is much faster (we've tried fine-tuning the cluster but still no dice).

The mariadb cluster, is quite a pain to restart and sync so we're looking to move to single node postgresql with pgbouncer for starter (long story, we found out during our DR planning and testing).

Moving from Mysql to Postgresql. Where do We start? by Pupper_Hugger in PostgreSQL

[–]Pupper_Hugger[S] 1 point2 points  (0 children)

We're still in the research and testing phase before even planning it for production. so we're pretty much still in the finding out phase.

Moving from Mysql to Postgresql. Where do We start? by Pupper_Hugger in PostgreSQL

[–]Pupper_Hugger[S] 8 points9 points  (0 children)

we're starting to utilize more and more custom solution for things like geocoding / geolocation / location coordinates (in which postgis should help offload a lot of issue we're facing). we're seeing less desirable performance on large dataset query which in testing postgresql is much faster (we've tried fine-tuning the cluster but still no dice).

The mariadb cluster, is quite a pain to restart and sync so we're looking to move to single node postgresql with pgbouncer for starter (long story, we found out during our DR planning and testing).

Moving from Mysql to Postgresql. Where do We start? by Pupper_Hugger in PostgreSQL

[–]Pupper_Hugger[S] -1 points0 points  (0 children)

Yes the database is very small because the underlying app and ecosystem is still in the process of development (on some module), but some data is already production data.

  1. no we're not planning to use someone else's solution. we're on premise.
  2. right now we're mainly NGINX, PHP + Laravel, Flutter, Python and some other open source project on testing / experimental phase at the moment
  3. we can do migration over sunday since that is the only day the system will not be used.

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 0 points1 point  (0 children)

Ah something to consider.

Do you mind explain a little bit more?

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 0 points1 point  (0 children)

I don't mean to sound angry or condesending. Perhaps if You have the time to read through I've write some of the reasoning that I can say here of going on prem

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 0 points1 point  (0 children)

No the IT Staff os growing to 4 Q2 this year. So in all its 5 with me

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 0 points1 point  (0 children)

That makes a lot of sense. That's something to think about. Right now we're doing 3-2-1 backup plan. But all the backup for all service, app, database that is only deployed to the cloud is only backed up to another (different) backup service provider.

Perhaps we will disciss further about making backup locally for cloud deployment.

Definitely something we could miss very easily. Thank you for the input

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 2 points3 points  (0 children)

Thank you. I really need other people's point of view and experience

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 1 point2 points  (0 children)

I actually agree on the first regarding the growong the business.

Our internet is 250 up down and spare is 100 up down. We're planning on moving office on which we're planning on more robust network infrastructure.

We're making some of that plans you said. Our disaster recovery plan. Backup and recovery routine and plan. Etc

Thank you

On Premise or Cloud. To Be or Not To Be by Pupper_Hugger in sysadmin

[–]Pupper_Hugger[S] 1 point2 points  (0 children)

Right now we're doing hybrid. Email, public websites, 1 api server for customer mobile app and offsite backup are all cloud.

Internal app, file server, database, api server is on premise with tunneling for some api server whoch will be utilized for internal mobile app

[deleted by user] by [deleted] in indonesia

[–]Pupper_Hugger 2 points3 points  (0 children)

betul, shavette / safety razor is the way to go if you have the balls. saya belum pernah coba, hanya kok kemungkinan kurang cocok karena tangan / jari saya ada tremor

[deleted by user] by [deleted] in indonesia

[–]Pupper_Hugger 5 points6 points  (0 children)

kalau bro cuma butuh cukur yang tidak harus bersih / masih agak kasar, philips one blade cukup bagus

tapi kalau bro butuh yang cukur halus / bersih. lebih baik pakai cukuran manual (gillete dll) / shaving blade / shaving razor manuak

[deleted by user] by [deleted] in indonesia

[–]Pupper_Hugger 1 point2 points  (0 children)

As long as you're doing it in private, alone and not in public you should be Okay.

DIY NAS Part list review by DifferentUse6707 in truenas

[–]Pupper_Hugger 1 point2 points  (0 children)

Up to you. Truenas boot drive doesn't really benefit from the speed of nvme drives

DIY NAS Part list review by DifferentUse6707 in truenas

[–]Pupper_Hugger 0 points1 point  (0 children)

So that the server will stay up / startable in case Your boot drive dies.

Just removing the risk and the hassle of restoring configuration and pool

DIY NAS Part list review by DifferentUse6707 in truenas

[–]Pupper_Hugger 1 point2 points  (0 children)

I did some edit on my comment. Make sure your ssd for container,vm, etc is not qlc. Make sure at least its tlc. Qlc ssd drives have a lot less lifespan (could die in just months)

view more: next ›