Date: Fri, 24 Jul 2020 16:52:51 -0400 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: "Steve O'Hara-Smith" <steve@sohara.org> Cc: Ralf Mardorf <ralf-mardorf@riseup.net>, FreeBSD Mailing List <freebsd-questions@freebsd.org>, Paul Pathiakis <pathiaki2@yahoo.com> Subject: Re: Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux Message-ID: <CAGBxaXkaG_bqtJMp7SfgW4ATxUtYM7C-MAaBWc2uKTFTzymaFA@mail.gmail.com> In-Reply-To: <20200724210127.7d05e22bd81b95388adf32ba@sohara.org> References: <20200214121620.GA80657@admin.sibptus.ru> <CAEJNuHwRs=6kOK9uiFzEAqCgSgvUb8Xm5o2VWnK-ND_zseowdg@mail.gmail.com> <20200214141600.GA82559@admin.sibptus.ru> <20200214204838.360c8f624397c659946bd764@sohara.org> <20200215063818.GE1482@admin.sibptus.ru> <20200215083359.367d8a3e9ddb4942df67d5b5@sohara.org> <58202623-bbf7-eda0-5cb5-fb4749e91e20@watters.ws> <CAEJNuHxbFSPBB7keSrBufpg=RsgQ8EPK_fvzt8XBROLNKyN_sw@mail.gmail.com> <6318251A-973A-4DEC-9271-12333EB11F7B@kicp.uchicago.edu> <CAEJNuHxC7i%2Bq7cq65=my6mJZDdiK4gpQsKjMU1nvsm=Ri4On%2Bg@mail.gmail.com> <800f33cd-0dc1-1ae9-2262-a374bf8c10dd@kicp.uchicago.edu> <20200724170348.51f108ec@archlinux> <1273868562.6647660.1595604615652@mail.yahoo.com> <20200724183331.6363d69c@archlinux> <CAGBxaXnky9nowCdSZd1maQN%2BeGQVm%2Boq%2BtfS-m0aAHhZJDqDPQ@mail.gmail.com> <20200724210127.7d05e22bd81b95388adf32ba@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 24, 2020 at 4:01 PM Steve O'Hara-Smith <steve@sohara.org> wrote: > On Fri, 24 Jul 2020 14:09:15 -0400 > Aryeh Friedman <aryeh.friedman@gmail.com> wrote: > > > spent 7 weeks denying that it was needed because they did block level > disk > > backups (I would love to hear from any DBA who would trust such > > backups!!!) > > Well so long as it streamed all changes to the backup in real time > and was guaranteed never to lose a block no matter what then I might trust > it for hot swap purposes but not for disaster recovery. > That is the reason why we requested replication not backup! (see below for what the hosting company absolutely refused to understand/believe) Did I mention that the database *MUST* stay up 24/7 since it is receiving real-time cardiac data for patients that are known (or at least strongly suspected to have heart conditions serious enough to need potential emergency open heart surgery) and the DB recieves over 1000 updates every 3 seconds that need to be processed in near real time? So no it is not possible to take it down (as is recommended by the MySQL manual and/or almost every blog out there)... So in order to avoid corrupting the DB on restore by backup incomplete transactions the only way is to lock the tables before backing it up (something that can only be done inside the DB not external with block only backups)... only problem here is it takes longer to back them up then 3 seconds and the client software is written by complete morons (who for example never even heard of concurrency as far we can tell) and thus just silent drops any data that can not be written to the DB (they blindly assume everything is a successful write). So therefore block backups are completely out the question (btw the DB is 21 GB and growing at 500 MB a month)... Let add one more complication the client wants us to auto populate the MySQL DB from our webapp DB which is on a physically separate machine, but refuses to buy a second license for the device DB software and thus we are forced to do our development/alpha testing on live data (i.e. we *MUST* have completely working backups made every 15 mins or so). In short this is the kind of project that makes the developers (us) need the devices we have connected to our webapp much sooner than later (if we ever needed them at all outside of this project). Grey hair would be the best possible outcome of this project! -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXkaG_bqtJMp7SfgW4ATxUtYM7C-MAaBWc2uKTFTzymaFA>